Aurelian Frontier — Proof Slice
This page describes the current runnable proof slice of the Aurelian Frontier game. It is the end-to-end example of a capOS-native interactive application: a Roman-frontier text adventure with magic wards, warrior skills, wizard spells, NPC chat history, per-player state, and explicit capability grants. The wider game design lives in Aurelian Frontier; this page covers what runs today and how the QEMU smoke proves it.
Unlike a shell builtin, the game runs as ordinary userspace processes:
capos-shelllaunchesadventure-clientwith onlyStdIO,Adventure, andChatclient capabilities.adventure-serverowns room, inventory, writ, combat, evidence, and effect state keyed by the endpoint caller-session scoped reference and epoch, while consuming validated read-only prototype mission content generated fromadventure-contentCUE source.chat-servercarries room messages and labels replayed room history so NPC actors do not treat old messages as fresh input.adventure-npc-wandererandadventure-npc-shopkeeperprove that separate actors can join the shared ashen-road channel without receiving ambient game authority.adventure-scenario-testis a noninteractive capOS userspace test process with onlyConsoleandAdventurecaps. It drives the custody scenario throughAdventureClientRPCs and prints a console success marker.
Run It
Use the focused QEMU proof:
make run-adventure
The scripted run creates a volatile shell credential, launches the interactive
adventure client for representative rendering and command coverage, and also
asserts the resident adventure-scenario-test success marker and exit status
for the complex custody path.
run "adventure-client" starts from a fresh expedition view by default. Use the
client’s resume command to return to that session’s active expedition state
instead of silently continuing it on launch.
For the default init-owned boot, start make run, log in or run setup, then
use the MOTD compatibility commands:
spawn "chat-server" with { console: @console, chat: @chat } -> $chat
spawn "adventure-server" with { console: @console, adventure: @adventure, chat: client @chat } -> $adventure
spawn "adventure-npc-wanderer" with { console: @console, chat: client @chat } -> $wanderer
spawn "adventure-npc-shopkeeper" with { console: @console, chat: client @chat } -> $shopkeeper
run "adventure-client" with { stdio: client @stdio, adventure: client @adventure, chat: client @chat }
Normal launch commands omit legacy receiver selectors; delegated client
endpoint identity is preserved by default. The adventure server derives player
state from live session-bound endpoint caller metadata. The focused
make run-adventure proof is the authoritative regression path. Its manifest
uses omitted-badge Adventure and chat service grants, while hostile and
lower-level smokes retain explicit selector fixtures for rejection coverage.
Current Mission
The implemented mission starts in fort_aurelian, crosses gate_yard and
ashen_road, and reaches signal_tower, with under_vault present as a
bounded site in the generated graph. The player can request and delegate a
ward-writ, ask actors about the mission, quote and buy Maro’s route support,
fight a ward-wraith, order Livia to expose the tower sigil, recover
eagle-standard, record a wounded-legionary evacuation, seal the gate-yard
breach, and get Iunia’s witness-certified temple-seal custody. Room views
show canonical room, exit, actor, mob, and writ ids alongside the current
mission and lead. Status and inventory separate survival, location, mission,
physical items, writs, relic custody, marks, evidence, effects, and the next
lead; status also prints the fixed smoke seed calendar (ashfall day 9,
ash-wind, ward-static), a bounded seasonal resource count/cap summary, and
a carried seasonal-resource forecast that names the next season’s degraded and
expired counts. Status also prints a concise regional frontier summary for the
generated settlement, outpost, and route metadata, plus a construction
foundation summary for generated blueprint, artifact, enchantment slot, and gate
metadata; construction jobs, material reservation, and full artifact crafting
gameplay are not implemented.
Status now also prints disabled-by-default optional fake-agent NPC budget
metadata: budget count, aggregate session token budget, tool-call budget, and
audit visibility. That is deterministic metadata for future optional chatter
and hints, not live LLM gameplay or autonomous NPC authority. Status also
prints the first local party foundation: a service-created local player label,
the current party leader/members/pending invites, scoped ward-writ
delegations, and recorded assists. Party labels are derived from live Adventure
caller-session keys and do not disclose global session or principal data. The
same service-local labels are used by the first physical-item transfer
foundation, transfer <item> to <player>, which mutates both player inventories
atomically inside Adventure, requires shared party membership, and refuses
relic custody such as eagle-standard. Currency escrow and two-client transfer
proof remain future work.
Valid near-miss ids such as ward and wraith return explicit suggestions.
The site graph, regional metadata, visible items, actors, mobs, aliases,
objectives, mission text, leads, and scripted proof-path metadata are authored in
demos/adventure-content/content/prototype.cue, generated into
demos/adventure-content/src/generated.rs, and validated by host tests before
the server consumes them.
Useful commands in the current game:
look
resume
status
request ward
request ward-writ
accept ward-writ
delegate ward-writ to livia
order Livia to guard
go east
go east
say hello road
take scout-marker
quote route from maro
buy route from maro
transfer scout-marker to player-1
go north
order livia to dispel-sigil
inspect ward-wraith
cast ember-dart ward-wraith
skill strike ward-wraith
recover eagle-standard
ask wounded-legionary about evacuation
guard
cast shield-bind self
go south
go west
seal gate
go west
ask iunia about custody
inventory
go down
What It Proves
make run-adventure currently asserts:
- shell-spawned game clients run with explicit
StdIO,Adventure, andChatgrants; - ordinary
adventure-clientlaunch andlookstart fresh, while the explicitresumecommand reloads active expedition state through anAdventurecap call; - room joins, movement, physical item pickup, typed relic recovery, inventory, status, and representative failure messages are visible in the terminal transcript;
give,ask,request,accept,delegate,order,seal,recover,revoke,quote,buy,sell,trade,transfer, andrepairare wired as typed adventure calls, not shell-special strings;adventure-clientexposesparty create,party invite,party accept,party leave,party delegate,assist, andtransfer <item> to <player>command paths backed by typed Adventure methods;- the party proof covers one-client party creation, missing local-player refusal paths for invite and assist, party status output, and help/client command availability; two-client successful accept, leave, delegate, and assist calls remain future work;
- the transfer proof covers one-client unknown target, self-transfer, and missing-item refusals, with status or inventory unchanged as appropriate; successful two-player transfer remains covered by pure Rust state tests until the launcher/session harness can run two real Adventure clients;
- canonical room, exit, actor, mob, and writ ids, room-view leads, common actor casing aliases, near-miss suggestions, and improved actor-task hints are visible in the terminal transcript;
- combat status exposes hp, guard, fatigue, warrior stars, wizard circles, prepared spells, active mobs, mission state, physical items, writ authority, relic custody, marks, evidence, effects, fixed smoke seed calendar state, and objective state;
- market coverage proves a Maro route quote, a successful route exchange, a
field-engineer repair response, and an Iunia clean-custody trade refusal that
names the
temple-sealgate and price; shell-smoke coverage also keeps the full market command-help surface, includingsell, visible; - delegated authority can expose the ward, repeated spell actions are
idempotent, and
eagle-standardrecovery records bounded evidence in the interactive transcript; - the
adventure-scenario-testprocess covers physical-item-onlytakeanddrop, Iunia custody denials, witness refusal, survivor evacuation, gate sealing,temple-sealcustody, categorized evidence tokens, andunder_vaultaccess through realAdventurecap calls, and asserts the fixed calendar, seasonal carry forecast, regional, construction foundation, agent NPC budget, and one-client party status lines through realAdventurecap calls; - the two-client local co-op proof remains open because the current focused manifest/session launcher path does not yet provide two distinct live Adventure caller-session keys without faking them inside one process;
- replayed room messages are labeled as history, and the named NPC actor proof accepts visible replies whether the player observes them live or through room-history replay after movement;
- the read-only prototype content model rejects malformed room graphs, bad aliases, overlong text, empty proof paths, malformed construction metadata, and invalid agent NPC budget metadata in host tests.
make generated-code-checkfails if the checked-in generated adventure content drifts from the CUE source or generator.
Design Context
The gameplay and future setting plan live in the Aurelian Frontier proposal. The proposal covers the Aurelian frontier setting with magic-warrior and wizard ranks, future mobs, portals, golems, logistics, campaigns, persistent shared world state, multiplayer, and how those mechanics map onto capability-native authority.