cyberia 3.2.12 → 3.2.22

package/src/client/public/cyberia-docs/ARCHITECTURE.md

@@ -1,78 +1,118 @@
-# Cyberia Architecture
+# Cyberia — Architecture
 
-Cyberia is the MMO extension that runs on top of Underpost Platform. Keep the model simple:
+Cyberia is the real-time MMO extension that runs on Underpost Platform. This document describes the three Cyberia processes, their boundaries, the data flow between them, and the canonical model for tick, snapshot, prediction, reconciliation, interpolation, and replication.
 
-- Underpost Platform provides the toolchain, deployment surface, PWA delivery, and base infrastructure.
-- `engine-cyberia` is the content authority.
-- `cyberia-server` is the authoritative simulation.
-- `cyberia-client` is the presentation runtime.
+Underpost Platform provides the toolchain, deployment surface, PWA delivery, and base infrastructure. The three Cyberia processes operate on top of it.
 
 ---
 
-## System map
+## Process model
 
-```text
-Underpost Platform
-  -> toolchain, deploy, PWA build, static delivery, monitoring
+```
+┌─────────────────────────────────────────────────────────────────────────┐
+│  UNDERPOST PLATFORM (infra · toolchain · deploy · PWA/Workbox)          │
+│                                                                          │
+│  ┌─────────────────────┐                                                 │
+│  │ Persistent backend  │   ← Cyberia content authority + asset backend   │
+│  │ ──────────────────  │                                                 │
+│  │  engine-cyberia     │     Node.js                                     │
+│  │  MongoDB            │                                                 │
+│  │  IPFS / Cloudinary  │                                                 │
+│  │  ObjectLayerToken   │     Hyperledger Besu (off-line dependency)      │
+│  └─────────┬───────────┘                                                 │
+│            │ gRPC (world load, hot reload)                               │
+│            ▼                                                             │
+│  ┌─────────────────────┐                                                 │
+│  │ Authoritative       │   ← Cyberia simulation authority                │
+│  │ simulation runtime  │                                                 │
+│  │ ──────────────────  │                                                 │
+│  │  cyberia-server     │     Go                                          │
+│  └─────────┬───────────┘                                                 │
+│            │ WebSocket (binary AOI snapshots, typed input commands)      │
+│            ▼                                                             │
+│  ┌─────────────────────┐                                                 │
+│  │ Presentation        │   ← Cyberia render + prediction client          │
+│  │ runtime             │                                                 │
+│  │ ──────────────────  │                                                 │
+│  │  cyberia-client     │     C / WebAssembly (Raylib · Emscripten)       │
+│  └─────────────────────┘                                                 │
+│            │                                                             │
+│            │ REST (atlas frames, asset metadata, optional client hints)  │
+│            └──→ engine-cyberia                                           │
+└─────────────────────────────────────────────────────────────────────────┘
+```
 
-engine-cyberia (Node.js)
-  -> content, validation, persistence, gRPC/REST data services, asset metadata
-  -> feeds cyberia-server and cyberia-client
+Three processes, strict role separation. The ecosystem is fully operational only when all three are running and healthy at the same time.
 
-cyberia-server (Go)
-  -> authoritative simulation and tick processing
-  -> feeds cyberia-client over WebSocket
+---
 
-cyberia-client (C/WASM)
-  -> rendering, input, prediction, presentation
-```
+## Role definitions
 
----
+### engine-cyberia (Node.js) — content authority
 
-## Responsibility split
+The content-authoring backend and persistence layer for Cyberia. Owns persisted data and exposes it through two transports: gRPC (consumed by `cyberia-server` at boot and during hot reload) and REST (consumed by `cyberia-client` for asset distribution and optional presentation overrides).
 
-| Service          | Owns                                                                      | Must not own                                  |
-| ---------------- | ------------------------------------------------------------------------- | --------------------------------------------- |
-| `engine-cyberia` | content, validation, persistence, gRPC/REST data services, asset metadata | authoritative simulation, render policy       |
-| `cyberia-server` | authoritative simulation, world tick, gameplay mutation, AOI replication  | content authority, presentation metadata      |
-| `cyberia-client` | rendering, input, prediction, interpolation, presentation                 | authoritative world state, gameplay authority |
+What it owns:
 
-Two boundaries are non-negotiable:
+- Content generation, validation, and persistence.
+- Maps, portals, object layers, atlas/sprite-sheet metadata.
+- World configuration: AOI radius, economy rules, skill rules, equipment rules, entity gameplay defaults.
+- Persisted character/quest/dialogue/action data.
+- gRPC `CyberiaDataService` for world load and content streaming.
+- REST APIs for assets and the optional client-hints overrides.
+- Static content distribution + Cloudinary-backed asset flow.
+- Editor and CLI integration for content workflows.
 
-- Do not move authoritative logic into the client.
-- Do not move content-authority logic into the Go runtime.
+What it does NOT own:
 
----
+- Real-time simulation. It is not a gameplay runtime.
+- Per-tick state advancement.
+- Client presentation policy (palette, camera, dev overlay, icon visuals).
+- World mutation during gameplay.
 
-## Data flow
+### cyberia-server (Go) — authoritative simulation runtime
 
-```text
-engine-cyberia --gRPC--> cyberia-server --WebSocket--> cyberia-client
-engine-cyberia --REST-------------------------------> cyberia-client
-```
+The tick-based authoritative simulation. Owns world state and the gameplay rules that mutate it.
 
-- `engine-cyberia` publishes world content, validation rules, persistence-backed data, and asset metadata.
-- `cyberia-server` loads authoritative world data, advances the simulation tick, and emits per-player AOI snapshots.
-- `cyberia-client` sends typed input commands upstream and renders the result locally with prediction and interpolation.
+What it owns:
 
-There is one source of truth per concern:
+- Authoritative world state.
+- The tick: a `uint32` advanced once per simulation step at a fixed `tickRate`.
+- Simulation phases — the only allowed mutators of world state.
+- AOI replication: per-player interest filtering and snapshot emission.
+- Input command processing: typed input commands drained from per-player queues each tick.
+- Snapshot generation and delivery via WebSocket.
 
-- Content and world configuration: `engine-cyberia`
-- Real-time authoritative state: `cyberia-server`
-- Presentation and local interaction: `cyberia-client`
+What it does NOT own:
 
----
+- Persistence (loaded once at boot from engine-cyberia).
+- Client presentation. The server holds no palette, no camera knobs, no dev-overlay flag, no status-icon visuals.
+
+### cyberia-client (C / WebAssembly) — presentation runtime
+
+The render and interactive runtime. Compiled to WASM via Emscripten and served as a Progressive Web App through the Underpost Platform delivery pipeline.
 
-## Operational guardrails
+What it owns:
 
-- Prefer one source of truth for config, deploy IDs, runtime selection, startup behavior, and generated assets.
-- Reuse existing helpers and conventions instead of creating parallel implementations.
-- Do not duplicate parsing, env resolution, or path normalization logic across modules.
-- Treat generated artifacts as outputs only; never hand-edit them.
+- Rendering and UI.
+- Input capture: raw OS events → typed input commands with monotonic sequence numbers.
+- Prediction of the local player.
+- Reconciliation against authoritative snapshots.
+- Interpolation of remote entities.
+- Presentation defaults (palette, status-icon visuals, camera knobs, interpolation window, dev-overlay flag) — loaded at startup from the client-hints REST endpoint.
+- Optional client-hints fetch for per-instance presentation overrides.
+
+What it does NOT own:
+
+- World simulation.
+- Economy outcomes, combat resolution, skill dispatch decisions.
+- Any state another client depends on for correctness.
 
 ---
 
-## Health states
+## Runtime operating model
+
+The three processes are supervised independently. Each service owns its own monitor and reconnector. The game is playable only when all three are healthy at the same time.
 
 | State      | Meaning                                                              |
 | ---------- | -------------------------------------------------------------------- |
@@ -80,4 +120,186 @@ There is one source of truth per concern:
 | `degraded` | at least one service is reconnecting or unavailable                  |
 | `standby`  | gameplay is paused because the full three-service set is not healthy |
 
-This is the model to document, operate, and monitor against.
+Dependency between services is handled by supervision and reconnect loops:
+
+- `cyberia-server` dials `engine-cyberia` gRPC at boot and exits on dial failure rather than fabricate a world. On reconnect, it reloads world configuration.
+- `cyberia-client` reconnects to `cyberia-server` over WebSocket and re-fetches content from `engine-cyberia` over REST independently.
+- If any one of the three services goes unhealthy, the game moves to standby until all three recover.
+
+Underpost Platform deploy orchestration ensures the backend layer is ready before the simulation layer is started, and the simulation layer is ready before the presentation layer connects. This ordering is an infrastructure concern, not a documentation model: the processes themselves are supervised and reconnect without requiring a manual restart chain.
+
+---
+
+## Tick model
+
+The tick is the universal coordinate of the simulation. Every server→client snapshot and every client→server input command carries a tick value.
+
+| Concept                  | Value                                 | Notes                                                                                                   |
+| ------------------------ | ------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| **tick**                 | `uint32`                              | Monotonic simulation step counter on `cyberia-server`. Resets only on world rebuild.                    |
+| **tick rate**            | Hz (default `30`)                     | Simulation frequency. Authoritative; comes from world configuration. The string "fps" is never used to describe the server. |
+| **snapshot rate**        | Hz (default `20`)                     | AOI replication frequency. Decoupled from tick rate so bandwidth scales independently of simulation fidelity. |
+| **tick duration**        | `1 / tick_rate`                       | The dt used by every simulation phase.                                                                  |
+| **client tick estimate** | derived                               | Client estimate of the server's current tick, used to stamp outgoing input commands.                    |
+| **render tick**          | `server_tick_estimate − INTERP_TICKS` | The tick the interpolation module samples remote entities at.                                           |
+
+Three clocks, one tick number: simulation tick (server), snapshot tick (server replication), render frame (client). The tick number is the only synchronization point.
+
+---
+
+## Simulation phases
+
+Inside one simulation tick, `cyberia-server` runs the following phases in fixed order. These are the only functions that mutate authoritative world state:
+
+1. `phaseInput` — drain each player's `InputQueue`; dispatch typed input commands to gameplay handlers.
+2. `phaseLifecycle` — respawn timers, despawn expirations.
+3. `phaseSkills` — skill projectile collisions.
+4. `phaseAI` — bot behaviour decisions.
+5. `phaseMovement` — integrate positions using `tickDuration`.
+6. `phasePortals` — portal entry and teleport.
+
+A separate ticker runs replication independently of the simulation:
+
+- `phaseReplication` — per player: compute AOI, encode snapshot, dispatch. Runs at `snapshotRate`.
+
+Phases never read presentation data. They consume world configuration loaded at boot (gameplay rules) and the input queue.
+
+---
+
+## Client render frame
+
+The render frame runs at vsync. Inside one render frame, `cyberia-client` performs:
+
+1. Poll any pending optional client-hints fetch.
+2. Capture raw input → build typed input command (`kind`, `clientTick`, `sequence`, payload) → apply to prediction → send on the wire.
+3. Reconcile against the latest snapshot: drop input commands ≤ `lastAckedSequence`, rewind self to authoritative position, replay unacked commands.
+4. Fixed-timestep simulation: while accumulator ≥ `tickDuration`, advance prediction one tick.
+5. Interpolation: compute remote-entity view positions at `renderTick`.
+6. Render. Read view models; never mutate world state.
+
+Render frame rate is independent of simulation tick rate. The fixed-timestep accumulator ensures the predicted simulation advances at the authoritative `tickRate` regardless of FPS.
+
+---
+
+## Wire protocol — AOI snapshot header
+
+Snapshots travel as binary WebSocket frames. The header carries the simulation tick and the per-player acknowledged input sequence.
+
+```
+Header (binary, little-endian, 11 bytes for AOI snapshots):
+  [0]       u8   msgType     0x01 = aoi_update, 0x03 = full_aoi
+  [1..4]    u32  tick        simulation tick at which the snapshot was produced
+  [5..8]    u32  lastAcked   highest InputCommand.Sequence applied for this player
+  [9..10]   u16  entityCount entity blocks that follow
+```
+
+Other message types (init data, FCT) use their own headers and are not part of the per-tick replication stream.
+
+---
+
+## Input command pipeline
+
+Client input flows through a typed pipeline. There is no JSON intermediate on the binary path. The simulation tick is the only consumer.
+
+```
+WS frame (binary)  →  decode  →  typed InputCommand{kind, clientTick, sequence, payload}
+                                              ↓
+                                              dispatchInputCommand
+                                              ↓
+                                              PlayerState.InputQueue (per-player, bounded)
+                                              ↓
+                       phaseInput (under world mutex, once per simulation tick)
+                                              ↓
+                       phase_input_handlers.go — typed dispatch per InputKind
+                                              ↓
+                       authoritative world state
+```
+
+`InputCommand.Sequence` is monotonic per client. The server tracks the highest applied sequence per player; `phaseReplication` writes it into every snapshot header. The client drops acknowledged input commands from its prediction replay buffer using this value.
+
+---
+
+## Presentation metadata ownership
+
+Presentation is client-owned. The authoritative server holds no presentation state.
+
+| Concern                                          | Owner                 | Mechanism                                                                       |
+| ------------------------------------------------ | --------------------- | ------------------------------------------------------------------------------- |
+| Palette (named ColorRGBA entries)                | engine-cyberia (REST) | served by `GET /api/cyberia-client-hints/:CYBERIA_CLIENT_HINTS_CODE`. Source schema: `SharedDefaultsCyberia.js`. |
+| Status-icon visuals (icon stems + border colors) | engine-cyberia (REST) | same                                                                            |
+| Per-entity-type fallback color keys              | engine-cyberia (REST) | same                                                                            |
+| Camera defaults (smoothing, zoom)                | engine-cyberia (REST) | same                                                                            |
+| Cell-pixel size, default object dims             | engine-cyberia (REST) | same                                                                            |
+| Interpolation window                             | engine-cyberia (REST) | same                                                                            |
+| Dev-overlay flag                                 | engine-cyberia (REST) | same                                                                            |
+| World configuration (gameplay rules)             | engine-cyberia (gRPC) | `CyberiaInstanceConf` — no presentation; only simulation                        |
+
+The cyberia-client carries **no** compile-time palette. `domain/presentation_runtime.{c,h}` fetches the full presentation surface on startup; until the fetch settles the runtime returns a tiny inline neutral-grey bootstrap so the splash screen has something to draw. The simulation is unaffected by the fetch outcome.
+
+`cyberia-server` never reads any presentation field. The only "representational" data on the simulation wire is the **active item IDs** carried inside each AOI snapshot. Everything else visual is the client's job, fed by the hints REST endpoint.
+
+---
+
+## Canonical vocabulary
+
+Every Cyberia document uses the same terms. Aliases are not permitted.
+
+| Term                      | Definition                                                                                                                |
+| ------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
+| **tick**                  | Monotonic simulation step counter.                                                                                        |
+| **tick rate**             | Simulation Hz on `cyberia-server`.                                                                                        |
+| **snapshot**              | AOI-filtered world view at one tick for one player.                                                                       |
+| **prediction**            | Optimistic local apply of input commands to the predicted self entity.                                                    |
+| **reconciliation**        | Drop acknowledged inputs, rewind self to authoritative position, replay unacked inputs.                                   |
+| **display smoothing**     | Per-render-frame exponential lerp from the discrete predicted self position to a continuous on-screen position. Decouples the visible main player from sim-tick boundaries. |
+| **interpolation**         | Render-time smoothing of remote entities, sampled from snapshot history.                                                  |
+| **authoritative server**  | `cyberia-server`. Sole authority on world state.                                                                          |
+| **content authority**     | `engine-cyberia`. Sole authority on persisted content and world configuration.                                            |
+| **client hints**          | Optional presentation overrides served by engine-cyberia.                                                                 |
+| **world configuration**   | Gameplay parameters loaded at server boot from engine-cyberia.                                                            |
+| **presentation metadata** | Render-only data. Client-owned.                                                                                           |
+| **input command**         | Typed client→server frame with kind, clientTick, sequence, payload.                                                       |
+| **AOI**                   | Area of interest — the spatial filter that defines which entities a given player receives.                                |
+| **replication**           | Production and delivery of snapshots from server to clients.                                                              |
+| **simulation phase**      | A named step inside one simulation tick.                                                                                  |
+| **healthy**               | All three Cyberia services up and connected; game is playable.                                                            |
+| **standby**               | Game paused because at least one of the three services is not healthy.                                                    |
+
+Forbidden usages:
+
+- "fps" on `cyberia-server` (use **tick rate**).
+- "frame-based" simulation language on the server.
+- "game_state" as a god object on the client.
+- Render metadata in `cyberia-server` state.
+- "engine" without qualifier when the project name is intended. Use **engine-cyberia** for the Cyberia content backend; use **Underpost Platform** for the umbrella product.
+
+---
+
+## Instance topology
+
+A `CyberiaInstance` (persisted in MongoDB, served by engine-cyberia) is a directed graph:
+
+- **Vertices** — `CyberiaMap` documents (grid-based maps).
+- **Edges** — `PortalEdge` records connecting source cell → target map/cell.
+
+Portal modes:
+
+| Mode           | Behaviour                                       |
+| -------------- | ----------------------------------------------- |
+| `inter-portal` | Teleport to a specific cell on a target map     |
+| `inter-random` | Teleport to a random valid cell on a target map |
+| `intra-portal` | Teleport within the same map to a specific cell |
+| `intra-random` | Teleport within the same map to a random cell   |
+
+Topology modes: `linear`, `hub-spoke`, `open`, `grid`.
+
+---
+
+## Entity types
+
+| Type           | Behavior              | Description                 |
+| -------------- | --------------------- | --------------------------- |
+| `player`       | interactive           | Local player (self)         |
+| `other_player` | interactive           | Remote players inside AOI   |
+| `bot`          | `hostile` / `passive` | AI-controlled entities      |
+| `skill`        | `skill`               | Runtime-spawned projectile  |

package/src/client/public/cyberia-docs/CYBERIA-SERVER.md

@@ -12,7 +12,7 @@
 
 `cyberia-server` is the authoritative simulation runtime for the Cyberia MMO extension on Underpost Platform. It owns world state, advances a fixed-rate tick, drains typed input commands from connected clients, and dispatches AOI-filtered snapshots on a separately-paced replication tick.
 
-It is **not** the content authority. World content is loaded from `engine-cyberia` over gRPC. It is **not** the render-policy authority. Presentation is owned by `cyberia-client`.
+It is **not** the content authority. World content is loaded once at boot from `engine-cyberia` over gRPC. It is **not** the render-policy authority. Presentation is owned by `cyberia-client`.
 
 ---
 
@@ -20,23 +20,32 @@ It is **not** the content authority. World content is loaded from `engine-cyberi
 
 Three independent processes, non-overlapping roles. The ecosystem is playable only when all three are running and healthy at the same time.
 
-```text
-engine-cyberia (Node.js)        cyberia-server (Go)            cyberia-client (C/WASM)
-content authority               authoritative simulation       presentation runtime
-gRPC + REST                     tick + AOI + snapshots         render + prediction
-
-   └── gRPC GetFullInstance ──►   └── WebSocket binary ──►
-         world config                  snapshots -> / input <-
+```
+engine-cyberia (Node.js)                cyberia-server (Go)              cyberia-client (C/WASM)
+─────────────────────────               ──────────────────               ──────────────────────
+content authority                       authoritative simulation         presentation runtime
+persisted maps + rules                  tick + AOI + snapshots           render + prediction
+
+      │  gRPC  GetFullInstance               │  WebSocket binary
+      │────────────────────────────────────► │  AOI snapshots + init
+      │  (world configuration:               │  ▲
+      │   AOI radius, economy,               │  │ typed input commands
+      │   skill, equipment,                  │  │
+      │   entity gameplay defaults)          │  │
+      │                                      │  │
+      ▼                                      ▼  ▼
+   (boot + hot reload)                   tick loop + replication
 ```
 
 - Each service is supervised independently and owns its own monitor and reconnector.
-- `cyberia-server` loads world configuration from `engine-cyberia` and does not fabricate a world.
+- `cyberia-server` dials `engine-cyberia` gRPC at boot and exits on dial failure rather than fabricate a world.
+- On reconnect, world configuration is reloaded via `GetFullInstance(instanceCode)`.
 - If any one of the three services is unhealthy, the game moves to standby until all three recover.
 
 The server speaks two protocols:
 
-- **gRPC inbound** to consume world configuration from `engine-cyberia`
-- **WebSocket binary** to deliver snapshots and accept typed input commands
+- **gRPC, inbound, at boot and hot reload:** consumes world configuration from `engine-cyberia`.
+- **WebSocket binary, ongoing:** delivers AOI snapshots to clients, accepts typed input commands.
 
 There is no per-tick traffic between `cyberia-server` and `engine-cyberia`, and no presentation authority in the Go runtime.
 

package/src/client/public/cyberia-docs/QUEST-SYSTEM.md

@@ -10,7 +10,7 @@ The Quest System is a **chain/tree-structured progression framework** linking NP
 
 Quests are defined server-side as MongoDB documents and delivered to the client through the Engine REST API. Progress is tracked per-player in `CyberiaQuestProgress` documents.
 
-> **Implementation status — Pre-alpha:** The Quest and QuestProgress MongoDB schemas and Engine REST API (`src/api/cyberia-quest`, `src/api/cyberia-quest-progress`) are defined and seeded. Go server integration (quest tracking, objective evaluation, reward delivery via FCT) is planned for the **Alpha milestone**. For pre-alpha, quest progress is ephemeral: it lives in the client session only and resets on page reload.
+> **Implementation status — Alpha (talk objectives):** The Quest and QuestProgress MongoDB schemas and Engine REST API (`src/api/cyberia-quest`, `src/api/cyberia-quest-progress`) are defined and seeded. The Go server fetches quest definitions at instance init and now evaluates `talk` objectives, grants quests, advances steps, and delivers rewards via FCT on completion (driven by `dlg_complete` — see ACTION-SYSTEM.md). `collect` and `kill` objective evaluation remains planned for a later Alpha increment. Quest progress is authoritative **per Go session** (in-memory) and best-effort mirrored to `POST /api/cyberia-quest-progress`; it resets on reconnect. The C client surfaces it through the **Quest Journal** (see below).
 
 ---
 
@@ -168,6 +168,28 @@ On quest completion, the Engine grants each `rewards[].{itemId, quantity}` to th
 
 ---
 
+## Quest Journal (client)
+
+The C client keeps a local `quest_store` (in `cyberia-client/src/ui/quest_store.c`)
+populated from two server sources — **no extra REST calls**:
+
+- `init_data.quests[]` — the player's active/completed snapshot on connect.
+- `dlg_ack.quests[]` — live upserts as quests are granted or completed.
+
+The **Quest Journal** modal (`ui/quest_journal.c`) renders this store on the
+right side below the map info modal: a three-section tree (Active / Completed /
+Failed), each section independently collapsible via the shared `ui_toggle`
+component, each with its own 10-per-page pagination cursor. The interaction
+bubble column on the left is collapsible by the same toggle pattern. Both panels
+default collapsed on screens narrower than 600 px. Collapse state is not
+persisted across sessions.
+
+Each server quest snapshot entry carries `{ code, title, description, status,
+activeStep, objectivesText }` so the journal can render rows and inline detail
+without re-fetching the quest definition.
+
+---
+
 ## Indexes
 
 ```javascript

package/src/client/public/cyberia-docs/ROADMAP.md

@@ -1,6 +1,6 @@
 # Cyberia Online — Development Roadmap
 
-**Current version:** 3.2.12 | **Target milestone:** Open Alpha
+**Current version:** 3.2.22 | **Target milestone:** Open Alpha
 
 ---
 

package/src/client/public/cyberia-docs/WHITE-PAPER.md

@@ -18,7 +18,7 @@ _Stackable Rendering Layers as a Unified Tokenized Reality_
 
 ---
 
-**Version:** 3.2.12 | **Status:** Draft | **Authors:** Underpost Engineering
+**Version:** 3.2.22 | **Status:** Draft | **Authors:** Underpost Engineering
 
 ---
 

package/src/db/mongo/MongooseDB.js

@@ -86,7 +86,8 @@ class MongooseDBService {
 
     const user = config.user || process.env.DB_USER || '';
     const password = config.password || process.env.DB_PASSWORD || '';
-    const directConnection = hosts.length === 1;
+    const hasExplicitReplicaSet = !!(config.replicaSet || process.env.DB_REPLICA_SET);
+    const directConnection = hosts.length === 1 && !hasExplicitReplicaSet;
     const replicaSet = directConnection
       ? ''
       : config.replicaSet || process.env.DB_REPLICA_SET || MONGODB_DEFAULT_REPLICA_SET;

package/src/index.js

@@ -44,7 +44,7 @@ class Underpost {
    * @type {String}
    * @memberof Underpost
    */
-  static version = 'v3.2.12';
+  static version = 'v3.2.22';
 
   /**
    * Required Node.js major version

package/src/runtime/cyberia-client/Dockerfile

@@ -1,9 +1,9 @@
 # BUILD_MODE: RELEASE | DEBUG
 ARG BUILD_MODE=RELEASE
 
-# --- Build Image
+# --- Build Image ---
 FROM rockylinux/rockylinux:9 AS builder
-# Re-declare ARG after FROM so it is in scope for RUN
+
 ARG BUILD_MODE=RELEASE
 
 RUN dnf -y update && \
@@ -44,7 +44,6 @@ RUN dnf groupinstall -y "Development Tools" && \
 ENV EMSDK=/opt/emsdk
 ENV PATH="${EMSDK}:${EMSDK}/upstream/emscripten:${PATH}"
 
-# Pin emsdk version for reproducible builds
 ARG EMSDK_VERSION=5.0.6
 WORKDIR /opt
 RUN git clone https://github.com/emscripten-core/emsdk.git ${EMSDK}
@@ -53,28 +52,14 @@ RUN ./emsdk install ${EMSDK_VERSION} && \
     ./emsdk activate ${EMSDK_VERSION}
 
 WORKDIR /cyberia-client
-# Build context is the cyberia-client project repo root (the workflow
-# in .github/workflows/docker-image.cyberia-client.ci.yml sets
-# context: . from the cyberia-client checkout). The legacy
-# engine-context layout (COPY cyberia-client/ .) is no longer used.
+
 COPY . .
 
-# `make clean` first so stale bin/ or build/ artefacts copied in from a
-# developer's local checkout (or a previous Docker layer cache hit)
-# can't shadow a fresh BUILD_MODE rebuild — e.g. mixing a DEBUG-mode
-# index.wasm with a RELEASE-mode index.js once produced the
-# "corrupted heap memory area" panic that masked the real Closure bug.
 RUN make -f Web.mk clean && make -f Web.mk all BUILD_MODE=${BUILD_MODE} OUTPUT_DIR=bin/
 
-# --- Runtime Image
+# --- Runtime Image ---
 FROM rockylinux/rockylinux:9 AS runtime
 
-# Runtime needs:
-#   - python3 (serves the built /bin/ static files via server.py)
-#   - nodejs + the underpost CLI globally, for the container-status
-#     lifecycle hooks invoked from conf.instances.json before / after
-#     launching server.py. Installing it at build time avoids the slow
-#     `npm install -g` startup the K8S cmd would otherwise repeat.
 ARG UNDERPOST_VERSION=3.2.9
 RUN dnf -y update && \
     dnf -y install epel-release && \
@@ -95,7 +80,4 @@ ENV CYBERIA_MODE=production
 
 EXPOSE 8081 8082
 
-# Default CMD when the image is run directly (not via K8S cmd).
-# In K8S deploys conf.instances.json supplies its own cmd that wraps
-# container-status hooks + this same server.py invocation.
 CMD ["sh", "-c", "exec python3 server.py ${CYBERIA_PORT} bin ${CYBERIA_MODE}"]

package/src/runtime/cyberia-client/Dockerfile.dev

@@ -1,22 +1,8 @@
 # cyberia-client DEV runtime image.
-#
-# Differences vs the production Dockerfile in this same directory:
-#   - Builds the C/WASM bundle with BUILD_MODE=DEBUG (raylib + emcc keep
-#     symbols, asserts, and DWARF info; the bundle is larger but
-#     debuggable in the browser devtools).
-#   - Default CYBERIA_MODE is `development` instead of `production`.
-#   - Default CYBERIA_PORT is `8082` (debug port) instead of `8081`.
-#   - Keeps `vim-minimal`, `lsof`, `strace`, `procps-ng` in the runtime
-#     image so the operator can attach and inspect a misbehaving pod.
-#   - Does NOT clean the npm cache.
-#
-# Selected automatically by `node bin run instance-build-manifest`
-# whenever the `--dev` flag is set; the production Dockerfile in the
-# same directory is used otherwise.
 
 ARG BUILD_MODE=DEBUG
 
-# --- Build Image
+# --- Build Image ---
 FROM rockylinux/rockylinux:9 AS builder
 ARG BUILD_MODE=DEBUG
 
@@ -48,14 +34,13 @@ RUN ./emsdk install ${EMSDK_VERSION} && \
     ./emsdk activate ${EMSDK_VERSION}
 
 WORKDIR /cyberia-client
-# Build context is the cyberia-client project repo root (see the
-# production Dockerfile in this directory for the rationale).
+
 COPY . .
 
 # Dev build: BUILD_MODE=DEBUG keeps symbols, asserts, source maps.
 RUN make -f Web.mk all BUILD_MODE=${BUILD_MODE} OUTPUT_DIR=bin/
 
-# --- Runtime Image
+# --- Runtime Image ---
 FROM rockylinux/rockylinux:9 AS runtime
 
 ARG UNDERPOST_VERSION=3.2.9

package/src/runtime/cyberia-server/Dockerfile

@@ -1,4 +1,4 @@
-# --- Build Image
+# --- Build Image ---
 FROM rockylinux/rockylinux:9 AS builder
 
 RUN dnf -y update && \
@@ -11,27 +11,16 @@ RUN dnf -y update && \
 
 WORKDIR /build
 
-# Build context is the cyberia-server project repo root (the workflow
-# in .github/workflows/docker-image.cyberia-server.ci.yml sets
-# context: . from the cyberia-server checkout). The legacy
-# engine-context layout (COPY cyberia-server/ .) is no longer used.
+
 COPY go.mod go.sum ./
 RUN go mod download
 
 COPY . ./
 RUN chmod +x build.sh && ./build.sh
 
-# --- Runtime Image
+# --- Runtime Image ---
 FROM rockylinux/rockylinux:9 AS runtime
 
-# Runtime needs:
-#   - the compiled Go binary (cyberia-server itself)
-#   - nodejs + the underpost CLI globally, for the container-status
-#     lifecycle hooks (`underpost config set container-status ...`) that
-#     the conf.instances.json cmd invokes before / after launching the
-#     server binary. Installing it at build time avoids the slow
-#     `npm install -g` startup the K8S cmd would otherwise have to do
-#     on every pod boot.
 ARG UNDERPOST_VERSION=3.2.9
 RUN dnf -y update && \
     dnf -y install epel-release && \
@@ -46,17 +35,8 @@ WORKDIR /home/dd/engine/cyberia-server
 
 COPY --from=builder /build/server ./server
 
-# Static SSR dashboard rendered by `node bin/cyberia run-workflow
-# build-server-dashboard --output-path <project-root>/public/index.html`
-# from inside the engine repo checkout. The Go server's findPublicDir()
-# hard-requires public/index.html at boot and log.Fatalf's without it.
-# CI writes the dashboard into ./public/ at the cyberia-server repo root
-# before docker build picks it up here.
 COPY public/ ./public/
 
 EXPOSE 8081
 
-# Default entrypoint when the image is run directly (not via K8S cmd).
-# In K8S deploys conf.instances.json supplies its own cmd that wraps env
-# sourcing + container-status hooks + this same binary.
 ENTRYPOINT ["/home/dd/engine/cyberia-server/server"]