AetherOS

Make agent changes understandable

AetherOS is an agent-first game-authoring engine built in C99, with raylib supporting its native editor. The core problem is practical: if an agent changes a project, how does the creator understand the proposed change, decide whether to accept it, and recover when it is wrong?

The project approaches that problem through structured authoring. A native editor and a deterministic Agent CLI share a runtime core for validation, applying changes, describing differences, and rollback. Plain JSON project data makes the authored world accessible outside the editor.

From a task note to a visible result

The first milestone establishes a small end-to-end workflow. A creator makes a project, draws a spatial context volume, attaches a task note, and saves. The CLI processes the project, and the editor reloads the resulting graybox content for review.

This onboarding slice connects intent to a visible change. It is deliberately narrower than unrestricted game generation: the important foundation is a repeatable path through project creation, task context, structured output, and inspection.

Separate proposing from applying

The next milestone makes changes explicit transactions. A proposal can be exported without modifying the project. Validation checks its structure and meaning. A diff describes the result before apply commits it to project data.

The same process accepts an external transaction file from another tool or agent. That keeps the contract at the boundary clear: outside tools supply structured changes, and the shared core determines whether those changes are valid.

This separation lets automation participate without making the editor a blind executor. It also makes the workflow testable without driving the graphical interface.

Undo has to survive the session

Rollback restores the pre-apply project snapshot, including after a reload. A durable event log records changes, and identifier counters remain monotonic across rollback so later work does not accidentally reuse earlier identities.

The documented Phase 2 signoff checks cover the internal propose/validate/diff/apply flow, external transactions, field-level failures, history artifacts, and rollback after reload. The recorded tests also confirm that rollback consumes the available snapshot and that subsequent proposals continue with safe identifiers.

These are small guarantees individually. Together, they make experimentation less fragile: the author can inspect a change and recover from it without depending on an open editor session.

The next problem is correction

The next milestone focuses on targeted authoring: selecting an entity or area, attaching a correction, sending that context through the CLI, and reviewing the proposed result. The planning keeps this correction loop ahead of broader engine features.

AetherOS does not yet include a full asset browser, behavior language, UI authoring system, multiplayer, or packaged runtime player. Those omissions keep the current project centered on its strongest question: how to make agent-assisted authoring reviewable and reversible before expanding what an agent is allowed to build.