# 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](../proposals/aurelian-frontier-proposal.md); 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-shell` launches `adventure-client` with only `StdIO`, `Adventure`, and
  `Chat` client capabilities.
- `adventure-server` owns 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 from
  `adventure-content` CUE source.
- `chat-server` carries room messages and labels replayed room history so NPC
  actors do not treat old messages as fresh input.
- `adventure-npc-wanderer` and `adventure-npc-shopkeeper` prove that separate
  actors can join the shared ashen-road channel without receiving ambient game
  authority.
- `adventure-scenario-test` is a noninteractive capOS userspace test process
  with only `Console` and `Adventure` caps. It drives the custody scenario
  through `AdventureClient` RPCs and prints a console success marker.

## Run It

Use the focused QEMU proof:

```bash
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:

```text
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 selector-free Adventure and chat endpoint grants, while hostile and
lower-level smokes retain explicit legacy 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. The current gameplay slice also lets active collectible
seasonal resources be taken at their site; carried crops, fish, and forage
participate in the next-season aging rule, while active repair-material
resources can be harvested without being treated as fragile seasonal carry
items. `ask quartermaster about season-transition` applies that aging rule:
expired crops are removed, fish/forage degrade to explicit `-degraded`
inventory tokens, and unknown or non-seasonal items stay unchanged. After the
audited debrief grants Aurelian standing, the quartermaster can sell one
bounded `field-ration` from the fixed-smoke per-expedition seasonal stock,
spending that standing and adding the ration to inventory. Ordinary inventory
is currently bounded to six slots. This is not a full seasonal economy or
persistent calendar advance.
Status also prints the active generated calendar event metadata for the fixed
seed: the `lantern-vigil` festival's actor-location, shop, witness, route, and
rumor overlays. These event fields are metadata/status only; actor movement,
event-driven shop mutation, witness blocking, route safety mutation, debrief
branching, quests, gifts, and affection are not implemented. Status also prints
active generated actor routine metadata for
named actors, selected from the fixed calendar plus the current mission and
emergency state: actor id, room id, routine kind/trigger, schedule/effect text,
authority stance, and metadata-only gameplay stance. These routine records do
not move actors or grant/revoke authority. Status also prints
a concise regional frontier summary for the generated settlement, outpost, and
route metadata, plus a concise regional market order-book summary for generated
market books, buy/sell orders, crossed pure matches, and receipt-ledger ids.
Market-eligible items are limited to ordinary seasonal resources, construction
materials, and explicit outpost produced/consumed supplies. Writs, relics,
actors, mobs, spells, skills, order tasks, and artifact/authority-gated
blueprint outputs are excluded. The first live regional market transaction
proof is bounded to one generated order-book match at a time: Adventure owns
reserve, commit, cancel/release, stale-version rejection, idempotent replay,
and ordered receipt facts behind existing `quote`, `buy`, and `sell` calls for
explicit `regional-market` proof actions. Fresh committed field-ration matches
now debit the player-local Aurelian chit balance once, decrement the seller
`ash_farm` field-ration stock once, accrue two service-owned regional market
fee chits once, credit two service-owned `ash_farm` seller-proceeds chits once,
and deliver the committed quantity into the player expedition inventory only
when ordinary inventory capacity can accept the full delivery; if capacity is
full, replaying `buy commit-field-ration from regional-market` can apply the
held delivery after ordinary items are dropped without spending, decrementing
stock, accruing fees, or crediting proceeds again. Commit replay does not
duplicate delivery, debit, outpost stock movement, fee accrual, or seller
proceeds. Commit `29c065a9` at `2026-04-30 17:41 UTC` added bounded order
expiry to live matching and reserve: fixed-smoke day 65 keeps the field-ration
proof active, while the scenario process proves a day-73 expired field-ration
reserve releases without status, inventory, currency, outpost stock, fee,
seller-proceeds, or delivery mutation. Commit `205fd6a0` at
`2026-04-30 18:40 UTC` added a bounded
service-owned fee withdrawal proof: `sell withdraw-fees to regional-market`
moves the two accrued regional-market fee chits into a service-owned treasury
record exactly once, status exposes the treasury balance, replay is stable, and
inventory, currency, outpost stock, seller proceeds, and delivery state do not
mutate. Commit `a547db3d` at `2026-04-30 19:43 UTC` adds a bounded receipt
snapshot/restore proof:
`buy receipt-snapshot from regional-market` clones the live regional
market receipt facts, reconstructs a separate transaction state, replays the
old field-ration commit against that reconstructed state, and returns proof
success without mutating live status or inventory.
Commit `4b44b32` at `2026-04-30 20:07 UTC` adds a bounded settlement-side
snapshot-view proof: `buy settlement-snapshot from regional-market` checks
applied delivery, debit, stock, fee, proceeds, and withdrawal ids plus the
current settlement balances, replays the committed field-ration fact and fee
withdrawal as already applied, and returns proof success without mutating live
status or inventory.
The construction-job receipt snapshot work is scoped to pure Rust construction
receipt snapshot semantics plus a size-constrained QEMU no-mutation probe.
Pure `adventure-content` tests restore a separate `ConstructionJobState` from
ordered field-repair job facts and validate malformed, over-capacity, and
non-closed snapshot shapes. The focused QEMU path drives `repair
receipt-snapshot with field-engineer` after the old completed repair only to
check status/inventory stability and confirm live construction state and
material stock are unchanged. The runtime command does not replay receipts
into the live construction service and is not durable restart loading or a
general construction persistence layer.
It does not yet move NPC stores, broader outpost inventories, durable currency
ledgers, durable seller-proceeds ledgers, profile ledger balances, fee
ledgers, durable calendar advancement, durable crash-recovery state, or
general economy behavior.
Status also prints a construction
foundation summary for
generated blueprint, artifact, enchantment slot, and gate metadata;
the first live construction-job proof is bounded to the field-engineer gate
repair path: Adventure owns reserve/start, completion, cancel/release,
stale-version rejection, idempotent replay, service-owned material holds and
restores, and ordered job facts behind existing `repair` calls. It does not yet
persist durable stock ledgers, replenish stock from outposts, update player
output/currency inventories, advance job time, persist crash-recovery state, or
provide general crafting/artifact gameplay.
Status now also prints disabled-by-default optional fake-agent NPC metadata:
budget count, supported fake-agent purpose count, aggregate session token
budget, tool-call budget, and audit visibility. That is deterministic metadata
for future optional chatter, hints, outpost summaries, personal routines,
nonbinding shop flavor, and festival reactions, 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, scripted proof-path metadata, named-item
inspection text, and prepared-spell inspection text 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:

```text
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
quote regional-field-ration from regional-market
buy reserve-field-ration from regional-market
buy commit-field-ration from regional-market
buy reserve-incense from regional-market
sell cancel-incense to regional-market
sell withdraw-fees to regional-market
transfer scout-marker to player-1
repair gate with field-engineer
repair retry-field-repair with field-engineer
repair complete-field-repair with field-engineer
repair stale-field-repair with field-engineer
repair reserve-cancel-field-repair with field-engineer
repair cancel-field-repair with field-engineer
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`, and `Chat`
  grants;
- ordinary `adventure-client` launch and `look` start fresh, while the explicit
  `resume` command reloads active expedition state through an `Adventure` cap
  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`, and `repair` are wired
  as typed adventure calls, not shell-special strings;
- `adventure-client` exposes `party create`, `party invite`, `party accept`,
  `party leave`, `party delegate`, `assist`, and `transfer <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;
- generated actor routine metadata is visible through status as structured
  status-only records filtered by the fixed calendar and current
  mission/emergency state;
- generated regional market order-book metadata is visible through status as
  aggregate metadata and pure non-mutating crossed-match counts only;
- market and construction coverage proves a Maro route quote, a successful
  route exchange, an Iunia clean-custody trade refusal that names the
  `temple-seal` gate and price, a bounded regional-market
  reserve/commit/retry/stale/release/cancel proof where the server owns the
  transaction state and receipt facts, and a bounded field-repair construction
  job proof where the server owns job state, service-owned material
  hold/release facts, held-stock mutation, and terminal facts; shell-smoke
  coverage also keeps the full market command-help surface, including `sell`,
  visible;
- delegated authority can expose the ward, repeated spell actions are
  idempotent, and `eagle-standard` recovery records bounded evidence in the
  interactive transcript;
- the `adventure-scenario-test` process covers physical-item-only `take` and
  `drop`, carried seasonal resource pickup, quartermaster-triggered seasonal
  inventory aging, post-debrief seasonal ration purchase, Iunia custody denials,
  witness refusal, survivor evacuation, gate sealing, `temple-seal` custody,
  categorized evidence tokens, and `under_vault` access through real
  `Adventure` cap calls, and asserts the fixed calendar, seasonal carry
  forecast, regional market delivery/replay, construction foundation,
  construction-job
  denial/reserve/replay/open-conflict/complete/stale/release/
  reserve-after-release paths, agent NPC budget, and one-client party status
  lines through real `Adventure` cap 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-check` fails 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](../proposals/aurelian-frontier-proposal.md). 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.