DREAMLANDA different role from command emulation
The DREAMLAND admin is the person who sets up and manages the simulation. Spiritguide takes their instructions and proposes changes to the world state managed by DREAMLAND. It does not impersonate the user's shell or generate a command result. This separates creative direction from the work of answering a user's next command.
The DREAMLAND admin can describe purpose, setting, constraints, relationships, and desired depth. Scenario facts belong in world profiles and state; reusable behavior prompts describe how the agents should behave rather than hard-coding each scenario.
Unlike event-triggered enrichment, Spiritguide is explicitly invoked and can make broader changes requested by a DREAMLAND admin. The two roles are not interchangeable permissions to modify the world.
Guide a live session
A live instruction targets one registered session. Its state update is applied under that session's lock. The next foreground command refreshes the command agent's state so an older checkpoint does not conceal the DREAMLAND admin's changes.
A dry run returns the parsed proposal for review without applying it. Invalid structured output reports that no state changes were applied. The DREAMLAND admin can inspect the proposed update instead of judging success only from a prose summary.
spiritguide --session SESSION_ID --dry-run Add a maintenance history consistent with this host's established role.This is an illustrative instruction for the DREAMLAND admin console. It is not a command to enter inside the simulated SSH shell.
Build without an active user session
Detached profile workflows construct a synthetic session from a blank world or an existing saved profile. Spiritguide works against that state and saves the resulting profile without requiring someone to stay logged in over SSH.
- Create: establish a new world from DREAMLAND admin direction.
- Update: revise an existing saved profile.
- Fork: copy a baseline to a new name, optionally applying another instruction.
spiritguide profile create research-world A maintained coastal observatory with an accessible public terminal.
spiritguide profile fork research-world research-world-variant
spiritguide profile create preview-world --dry-run A maintained coastal observatory with an accessible public terminal.These examples illustrate the workflow, not bundled scenario names. Forking makes an experimental branch explicit rather than silently rewriting the baseline used by another run.
A generated world needs a valid entry
Saved profiles require valid entry and active-host references, registered host records, and authored initial-login banners. Detached save validation rejects an incomplete or malformed result before saving; dry runs expose those contract failures as well.
The ordinary initial banner is saved world content. It can display before the first prompt without an extra model call or waiting for enrichment. Later simulated logins remain part of the command emulation.
The default detached profile depth is world: preserve durable anchors and generated artifacts while excluding shell position and command history. A system profile can also carry system identity. Stateful emulation explains the save depths.
Separate authoring from evaluation
For a world-building experiment, keep the premise and constraints recorded before comparing generated results. Capture the generated artifact and its validation outcome, not just whether the model returned text.
Detached operations support per-operation Spiritguide settings, while admin MCP evaluation sessions can give each runtime role independent settings. These controls let a researcher vary the authoring model separately from the command emulator and enrichment roles.
Distinct generated profiles are distinct experimental starting points. Reusing a saved baseline helps compare exploration behavior, but model outputs remain variable and repeated runs still matter.