Proposal: Aurelian Frontier

Design for the Aurelian Frontier game: a capability-native, persistent-world RPG set on the imperial frontier of an original late-imperial fantasy setting. The current shell-spawned adventure-client artifact remains the deterministic proof slice for the capability system; this proposal describes the game it grows into. Both purposes coexist: the QEMU smoke transcript stays stable, and the design supports a long-running campaign with authoritative shared world state, multiplayer parties, durable profiles, and audited public history.

Current State

The existing artifact proves useful plumbing:

• capos-shell launches adventure-client as an ordinary child process.
• The shell grants explicit StdIO, Adventure, and Chat endpoint clients.
• adventure-server owns per-player room and inventory state keyed by the endpoint caller-session scoped reference and epoch; normal shell launch syntax omits legacy receiver selectors, and remaining explicit selector fixtures are not the adventure player identity model.
• chat-server carries room-local events and simple NPC process output.
• Focused make run-adventure transcript coverage proves launch, movement, item pickup, inventory, chat, and process exit; the resident adventure-scenario-test process covers complex custody logic through direct Adventure cap calls.

As a game, the playable surface is still narrow: one mission, one party of named actors, one tactical encounter. The Aurelian frontier map has replaced the four-room cellar prototype. The first mission recovers eagle-standard from signal_tower, uses Maro route evidence, Livia ward delegation, survivor evacuation, Iunia witness-certified custody, and gate sealing, and keeps the read-only site graph, mission text, aliases, objectives, metadata, and proof path in CUE-authored content with checked-in generated Rust output and freshness verification. Inventory and status now distinguish physical items, writs, relic custody, marks, evidence, generated calendar/regional/construction metadata, and disabled-by-default optional fake-agent NPC budget metadata. Direct NPC game authority remains future work. Room chat history is service persistence rather than player-owned adventure state. The agent NPC foundation is deterministic quota/refusal metadata and pure fake-model logic only; live LLM calls, hosted-agent services, durable NPC memory, and autonomous NPC actions are not implemented. Commit f149119 at 2026-04-29 09:09 UTC landed the pure targeted-combat foundation in adventure-content: deterministic combat zones, damage kinds, attack and mob profiles, bounded zone damage, fatigue, interruption, recognition, and alert propagation. Generated combat content, server integration, command parsing, and scenario proof remain open.

Subsequent phases keep the same capability architecture and grow the playable surface: more missions, more sites, durable profiles, persistent shared world state, party multiplayer, lawful PvP, an authoritative ledger of public history, and a richer presentation client. The deterministic transcript stays the proof gate; the game is what those transcripts increasingly exercise.

Setting

Working title: The Ninth Gate of Aurelian.

The game is set in an original late-imperial fantasy frontier: a Roman-like empire holds a fortified border against a hostile magical domain beyond a chain of unstable gates. Its frontier forces are mixed cohorts of shield soldiers, oath-bound magical warriors, field wizards, scouts, engineers, priests, and contracted hunters. Their authority is formal, audited, and revocable: orders, route rights, gate keys, supply access, spell licenses, and relic custody are all concrete grants.

The setting should emphasize duty, command culture, dangerous expeditionary work, practical battlefield magic, and rivalry between imperial command, temple witnesses, guild contractors, and licensed war mages. Those are broad genre ingredients. The capOS version must keep its empire, factions, locations, artifacts, NPCs, magic vocabulary, and plot original to capOS.

Core Fantasy

The player is a junior imperial operator assigned to a frontier gate-fort after a failed expedition. They are not a chosen-one archmage. They are useful because they can hold and delegate unusual authority safely: command passes, ward keys, evidence seals, squad orders, relic handles, and restricted gate routes.

The fantasy is not “collect three objects in four rooms” and it is not permission management with fantasy labels. The target fantasy is:

I gain rare authority, use it to enter forbidden places, command trusted
agents, bind dangerous relics, expose corrupt actors, and reshape the
frontier.

That means:

• receive a narrow mission grant,
• choose writs, companions, relics, and supplies,
• inspect a dangerous frontier site,
• discover conflicts between military, temple, guild, rebel, and wizard authorities,
• fight, negotiate, delegate, expose, or revoke instead of only attacking,
• route capabilities to allies who can act on them,
• survive magical incidents with limited tools,
• return with proof, prisoners, recovered relics, or a sealed gate.

That maps cleanly to capOS. Every interesting magical or political permission can be represented as a capability, and the player experience can expose the same idea through in-world language.

The game shape is a compact expedition RPG first:

accept mission
choose writs / companions / relics
enter dangerous site
discover authority conflicts
fight / negotiate / delegate / revoke
extract with loot, survivors, evidence, or consequences
upgrade rank, base, companions, and future authority

Every major RPG system should answer one question: how does this change what the player is lawfully, socially, or supernaturally able to do? If a feature only adds generic RPG numbers, cut it or make it authority-native.

Design Goals

• Make the first ten minutes of any session engaging, and leave room for a long-running campaign across many sessions, profiles, and parties.
• Keep all game verbs backed by typed service calls.
• Use NPCs as processes with explicit caps, not scripted text pasted into the client.
• Make authority visible: the player should understand what they are allowed to do and why.
• Make revocation and delegation part of play without turning the UI into an OS lecture.
• Make the next useful command discoverable from room text, status text, NPC advice, or command completions instead of requiring source reading.
• Keep exact object and actor ids player-facing and stable, with aliases only as convenience paths to the canonical ids.
• Preserve deterministic QEMU transcript coverage for proof slices, even as the wider game grows seeded variation, persistent world state, and multiplayer.
• Demonstrate that the capability model is usable from more than one application language. Rust and Lua game code should both operate through typed caps; neither language should receive ambient authority.
• Treat the persistent shared world as a real product surface: profiles, ledgers, expedition checkpoints, faction history, market state, and contributor evidence all live in capability-bounded services with authoritative server ownership.

Non-Goals

• A parser-combinator text adventure.
• Random combat outcomes inside the deterministic QEMU smoke proof. Variance in normal play is fine; transcript-critical paths must remain reproducible under a fixed mission seed.
• Copyright-compatible retelling of any source novel.
• Kernel-side game state. The kernel enforces capability authority; mission, profile, ledger, and world state belong in userspace services.
• A user-owned save blob as authority over public world facts. User-owned Drive/Firebase capsules may back up private profile and explicit expedition state, but ledger records, multiplayer outcomes, market receipts, and contributor rewards remain server-authoritative.

Intuitiveness Layer

The current artifact exposes the right command categories but makes the player do too much vocabulary discovery. The next phase should treat every room view, inspection result, and failure message as part of the control surface.

Principles:

• Always print canonical ids for objects, actors, mobs, writs, and exits.
• Accept forgiving aliases such as livia, Livia, and magister only after resolving them to one canonical id in the response text.
• When a command nearly matches a known id, return a suggestion: No broker offers ward here. Did you mean request ward-writ?
• When an actor cannot execute an order, list one or two valid tasks if the player has enough information: Livia cannot execute guard. With ward-writ delegated, try order livia to dispel-sigil.
• look should show the current objective, visible interactables, present actors, hostile mobs, and one short “lead” line when the player is stuck.
• status should separate survival state from mission state so players can scan it quickly:

Status: hp 12/14, guard 5, fatigue 0
Mission: expose the tower sigil, defeat ward-wraith, seal gate
Held: ward-writ accepted
Delegated: ward-writ -> livia
Lead: Livia needs line of sight; stand in the signal tower and order dispel-sigil.

Failure text should preserve causality. A refusal should say whether the missing piece is location, knowledge, authority, inventory, rank, cooldown, or target state. That makes the game feel fair and also teaches the capability model without naming kernel concepts.

Denial should usually reward the player with a lead. A blocked action can reveal a missing witness, unknown jurisdiction, forged seal, rival grant, corrupt actor, unsafe state, rank gate, or alternate route:

The gate refuses your route grant. It names the tower road, not the aqueduct.
Mira notices an old witness mark beside the lock.

Secrets and incomplete jurisdiction knowledge are core RPG fuel. The player should often discover that they are blocked because they do not yet understand who has authority here, not because they lack a generic key.

The current text parser can implement the first half of this through canonical ids, aliases, and suggestions. The later CommandSession path should expose the same hints as dynamic completions rather than duplicating a parser.

Scripting And NPC Brains

The kernel capability model should enforce authority. The adventure service, Lua scripts, NPC processes, and any later agent runners are ordinary userspace clients of that model. They should hold only the caps their role needs and exercise world mutation through typed service calls.

Rust should remain the default for core service code, bounded simulation, and proof-critical state transitions. Once Lua Scripting exists, Lua is a good fit for deterministic scenario glue: mission beats, dialogue state machines, quest-board text, debrief variants, and scripted NPC reactions. Lua scripts should receive narrow host APIs and object caps; they should not receive raw cap IDs, broad spawn authority, or a way to bypass Rust service validation.

This is useful for the game because it proves the capability model is not a Rust-only convention. A transcript can show a Rust service and a Lua-scripted NPC both using typed authority correctly, including one denied ungranted path.

For NPC behavior that does not need deterministic transcript output, the Language Models and Agent Runtime design is the better fit. LLM-backed NPCs can provide tavern chatter, optional hints, flavor summaries, or reactive dialogue, but their output should be treated as data. They must not decide mission-critical authority, relic custody, combat damage, or policy denials, and they should not sit on the main QEMU proof path unless served by a deterministic stub.

Long-lived or agent-controlled NPCs should also inherit the hosted-agent harness constraints from capOS-Hosted Agent Swarms. An NPC agent is a task-like process with a workspace/memory scope, advertised tools, audit, and budget, not an ambient identity. The adventure-specific budget should include per-NPC, per-session, and per-game-day token quotas, tool-call quotas, cooldowns, and model profiles. When quota, fatigue, sleep schedule, or policy blocks an answer, the NPC should refuse in-world, for example: I'm tired. Going to sleep. That refusal is part of gameplay state and audit, not a transport failure. Any memory/reflection output from the agent remains low-authority data until compiled into deterministic content or service-owned state through reviewed rules.

Player Loop

The 30-second loop is one meaningful command and one consequence:

1. Explore, inspect, fight, negotiate, unlock, delegate, or extract.
2. Receive at least one result: loot, map knowledge, danger, faction change, clue, shortcut, companion reaction, or new authority state.
3. Re-evaluate the site with better or worse information.

The 10-minute loop is a writ-backed expedition:

1. Briefing: an officer grants a mission writ and one restricted gate route.
2. Preparation: the player chooses route, companion, relic loadout, and helper authorities such as ward-writ, scout-order, medic-token, or relic-seal.
3. Expedition: the player enters two or three connected frontier locations.
4. Encounter: a surprise reveals an authority conflict, enemy trick, secret jurisdiction fact, companion risk, or faction demand.
5. Consequence: NPCs respond, a route opens or closes, and logs/evidence update.
6. Extraction: the player returns with survivors, relics, evidence, scars, or consequences.

The multi-session loop is frontier reshaping:

1. Increase rank and unlock new jurisdictions.
2. Upgrade the base, temple, archive, court, and other authority modules.
3. Build faction reputation and expose larger conspiracies.
4. Gain companions, alter their trust and doctrine, and decide who can safely hold delegated power.
5. Unlock future missions by expanding legal reach, not just damage and health.

Each loop should contain one deliberate choice, one reversible mistake, and one visible consequence. For example, the player can spend coin to buy a safe route, persuade the scout and keep the coin, or skip the route and risk an ambush. The transcript remains deterministic, but the player sees that the world is not a single locked command sequence.

The first implementation can cover one mission:

Mission: recover the missing eagle standard from the ruined signal tower.

Complication:
- the tower gate is unstable,
- a wounded legionary is trapped behind a ward,
- a guild scout wants payment before sharing a safe route,
- a temple witness refuses to certify the relic unless the player has not used
  a forbidden oath rite.

Good outcomes:
- standard recovered,
- survivor evacuated,
- gate sealed,
- scout paid or persuaded,
- temple witness records clean custody.

Narrative Model

The game should read like a compact expedition report unfolding through play, not like a list of room fixtures. The server owns mission state; NPC processes own voice, advice, rumors, and local reactions.

Use mission beats:

• briefed: Varro states the objective and offers two optional authorities.
• crossed-gate: the gate opens, chat switches from fort traffic to field traffic, and old fort chatter becomes history.
• first-contact: the first hostile sign teaches inspect and intent text.
• complication: a survivor, relic, or blocked route forces a tradeoff.
• turning-point: the player delegates, spends, steals, persuades, or fights.
• extraction: the player returns with relics, witnesses, prisoners, or sealed-route proof.
• debrief: rank marks, faction opinion, and audit records update.

Narrative should be stateful and short. A room description can have variants before and after key facts are known, but it should not become walls of prose:

Ashen Road
Signal ash drifts across the old paving stones. Maro has marked a narrow
ditch-route east.
Exits: west tower-east ditch-east
Actors: maro
Lead: ask maro about route, or inspect ash-tracks.

NPCs should surface stakes. Livia cares about unstable wards, Varro cares about orders and casualties, Iunia cares about custody and forbidden rites, and Maro cares about payment, favors, and survival. Their objections create interesting command choices rather than static lore.

World Model

Replace the current static room list with a small graph of Site records:

site_id
title
description
region
threat_level
exits
visible_items
actors
active_wards
required_route_cap

Keep the first map small:

• fort_aurelian: command room, quartermaster, temple annex.
• gate_yard: portal control, squad muster, unstable gate.
• ashen_road: contested approach with scout and ambush traces.
• signal_tower: relic objective, wounded soldier, ward puzzle.
• under_vault: optional dangerous route with an oath-echo hook.

The wider game should grow this into multiple settlements and outposts rather than a single hub with more rooms. fort_aurelian stays the first proof settlement. Later content can add a civilian city, a temple-administered site, a guild waystation, and resource-producing outposts such as mines, farms, timber camps, shrines, salvage yards, gate-yards, and repair yards. Routes between them carry distance, hazard, faction control, seasonal closure, cargo-limit, and authority metadata. Outposts produce bounded resources and consume supplies through service-owned state; user save capsules can back up private profile data but cannot invent public production or market facts.

Items should become capabilities or evidence, not inert nouns:

• eagle_standard: relic custody cap; proves mission objective.
• ward_writ: authority to request ward changes, but logs every use.
• scout_marker: grants access to hidden route hints.
• oath_echo: one-use inherited rite; powerful but politically risky.
• temple_seal: certifies clean custody if conditions are met.

Actors

NPCs should be separate processes where possible:

• Centurion Varro: mission issuer, grants route and squad authority.
• Magister Livia: battlefield wizard, can identify ward failures.
• Acolyte Iunia: temple witness, audits relic custody and forbidden magic.
• Maro the Guild Scout: knows routes, trades in favors, can withhold help.
• Wounded Legionary: rescue objective and source of battlefield facts.
• Gate Echo: hostile magical presence that can corrupt routes or chat.

Each actor should own only the caps that fit its role. For example, the scout does not get relic custody, and the temple witness does not get squad command.

Mechanics

Authority As Inventory

The current inventory is just strings. Split the player-facing inventory view into:

• items: physical objects visible in rooms,
• writs: mission and faction permissions,
• relics: dangerous objects with custody rules,
• marks: progression/rank state,
• evidence: facts or signed observations.

Player-facing commands can still say inventory, but output should show why each entry matters:

Writs:
  gate-route: tower approach, expires after return
  ward-writ: request imperial ward changes, audited
Relics:
  none
Evidence:
  broken sigil: tower ward failed from inside

This view must not imply that all entries are picked up with take. Physical objects use take and drop. Authorities use explicit grant, delegation, or custody verbs:

• request <writ> asks an actor or broker for a grant.
• accept <writ> receives a grant already offered by an actor.
• delegate <writ> to <actor> grants a scoped child or NPC authority.
• revoke <writ> withdraws authority when the holder allows it.

Failure text should distinguish object state from authority state:

You can see the southern ward, but your mission writ names only the tower gate.
Centurion Varro has not offered squad command authority.
The relic can be carried only after a temple witness seals custody.

Writs As Loot

Writs are RPG loot, not boring quest permissions. A writ is gear, skill tree, access key, and social status at the same time:

A good writ should feel like “this changes what I can do,” not “this allows the next quest step.” Writs can carry bounded affixes and drawbacks:

Route Grant of Urgency
- Allows passage through old aqueduct
- Expires after 40 turns
- Cannot be delegated
- +1 faction trust if survivor extracted

Custody Writ of Burden
- Allows carrying sealed relic
- Reduces combat initiative
- Requires witness before transfer
- Breaking custody causes temple penalty

The modifier set must remain deterministic under the mission seed. A writ must make issuer, scope, expiry, allowed verbs, delegation rules, drawbacks, and revocation conditions inspectable.

Authority Archetypes

Classes are authority archetypes, not generic stat packages:

Two archetypes may share combat numbers, but they should solve blocked situations with different verbs. A Warden invokes sanctuary, a Factor proves a supply right, an Archivist exposes the old seal, and a Heretic breaks the seal at a cost.

Delegation Buildcraft

Delegation is buildcraft. Companions are fallible agents, not portable stat bonuses:

The player’s build is partly deciding which powers to keep, which to delegate, and whom to trust. Carrying a relic personally may block entry to a polluted shrine. Delegating custody may free the player to act, but the companion can be bribed, frightened, corrupted, or forced to testify later. The service owns the deterministic result and prints the cause.

Item Use

Add explicit verbs:

• use <thing>
• give <thing> to <actor>
• ask <actor> about <topic>
• inspect <thing>
• seal <site|gate|relic>
• request <writ>
• accept <writ>
• delegate <writ> to <actor>
• revoke <writ>
• order <actor> to <task>

The service validates authority and state. Invalid actions should return specific text, not just the unchanged room.

Progression

Use a small rank model:

• tiro: recruit/operator, tutorial grants only.
• signifer: can carry relic custody.
• centurion: can issue squad orders.
• legate: future high-authority profile.

This is not a stats grind. Rank changes which capabilities the broker may grant in later missions. Magic progression can mirror this with circles:

• first circle: detect wards,
• second circle: reinforce shields,
• third circle: stabilize a minor gate.

Progression should unlock reach, not only power:

Can issue temporary ward writs
Can enter disputed shrines
Can appoint one field deputy
Can challenge forged grants
Can hold two relics in custody
Can revoke delegated authority remotely
Can negotiate with hostile jurisdictions
Can operate without local witness once per mission

Base modules should also create new verbs, not passive bonuses:

Combat

Combat should exist, but it should stay tactical and bounded. The first interesting version does not need a full roguelike engine, but it does need enemies, danger, skills, spells, and readable outcomes.

Combat is turn-based at the command level. A fight starts when the player enters a hostile site, triggers a ward, fails a negotiation, or chooses to engage. Each turn the player picks one action, allied NPCs act if present, then hostile mobs act. The transcript should stay deterministic for smoke coverage. Combat should attack authority as well as HP. The distinctive tactical question is whether the player can keep lawful control while under pressure.

Enemy types should interact with authority directly:

Good tactical verbs include:

inspect seal
challenge authority
bind relic
revoke grant
delegate ward to Mira
force witness
seal exit
expose forgery
claim custody
invoke sanctuary

Later combat can borrow a narrow set of Evil Islands-style tactical mechanics without inheriting its real-time randomness or punitive retreat traps. The grounding is recorded in Game Mechanics Prior Art. The useful ideas are visible preparation, careful fight selection, body-zone targeting, damage-type and armor interaction, stealth openings, and cast-time risk. Aurelian should translate those into deterministic command outcomes: scouting reveals threat and intent, inspected enemies expose vulnerable zones, weapons and spells target bounded zones, and failed positioning has explicit costs.

Player actions:

• shield a wounded soldier with ward-writ,
• call a legionary NPC if holding squad-order,
• use oath_echo to bypass a lock at political cost,
• attack with a weapon skill,
• cast a prepared spell,
• guard, retreat, seal a route, or order an ally.

This gives the player real decisions without turning combat into repeated attack commands.

Targeted attacks should stay small and readable:

attack ward-wraith head with spear
attack imp-scout legs
cast ember-dart at ghoul hands

Zone effects are deterministic and bounded:

• head: harder to land, can increase critical or disruption outcomes;
• hands: can reduce attack cadence, weapon use, or casting stability;
• legs: can slow pursuit, block retreat prevention, or weaken charge intent;
• core: the default reliable target, lower risk and lower swing.

Damage and mitigation should consider weapon type, spell type, zone armor, ward state, and inspected knowledge. A spear against a lightly armored weak point, a mace against armored limbs, or a ward spell against a revealed sigil should feel different in transcript text and outcome. The service still owns the exact result; clients do not roll hidden dice.

Mobs

Mobs should be small state machines owned by the adventure service or by separate actor processes once that split is useful. Initial mob types:

• imp-scout: weak, fast, tries to flee and report.
• ash-ghoul: slow melee enemy, punishes unguarded players.
• ward-wraith: ignores ordinary weapons until a ward is inspected or broken.
• gate-hound: blocks retreat unless stunned or distracted.
• echo-centurion: elite magical-warrior enemy used as a mission boss.

Each mob has:

name
threat_level
hp
armor
zone_armor
ward
attack
morale
traits
intent

intent is visible when the player has scout or wizard support:

The gate-hound lowers its head. Intent: lunge at the weakest target.
The ward-wraith gathers blue fire. Intent: break shield next turn.

This makes fights more interesting than hidden dice rolls.

Unknown enemies should not expose full mechanical truth immediately. A scout, wizard, height advantage, prior codex evidence, or an inspection action can upgrade the view from rough threat to exact armor/ward/intent/counter data. That keeps stealth and observation relevant without forcing real-time mouse precision.

Basic Stats

Use a small stat block:

vigor      physical endurance and wound tolerance
discipline morale, command, resistance to fear
edge       weapon accuracy and quick action
ward       magical defense and shield capacity
focus      spell control and ritual stability

Derived values:

hp         8 + vigor * 2
guard      discipline + ward
initiative edge + focus
load       vigor + discipline

The player should see compact status:

Status: hp 12/14, guard 5, fatigue 1
Ranks: warrior 2 stars, wizard 1 circle
Prepared: shield-bind, ember-dart
Writs: tower route, ward-writ

Stats are not the main reward system. They exist so combat and spell choices are legible.

Leveling And Reputation

Progression should reward mission outcomes rather than enemy grinding. A successful debrief can grant:

• rank marks: unlocks brokered authorities such as relic custody or squad order;
• warrior stars: unlocks martial and command skills;
• wizard circles: unlocks prepared spells and restricted ritual caps;
• faction standing: changes prices, testimony, help, and PvP legal status;
• codex entries: records inspected wards, mobs, relics, and route hazards.

Progression inputs should be auditable mission facts:

Recovered eagle-standard: +1 imperial standing
Evacuated wounded-legionary: +1 cohort standing
Used oath-echo: +1 breach power, -1 temple standing
Sealed gate with witness present: unlock relic-custody eligibility

Rank is therefore a policy input, not just a number. A player may be strong enough to win a fight but still unable to receive temple-seal authority after abusing forbidden magic.

Stars And Circles

Use separate progression tracks for martial and magical competence.

Warrior stars:

Wizard circles:

Stars and circles are player-facing rank labels, not copied external lore. Implementation may rename them if a stronger capOS-specific vocabulary emerges. Both are capability policy inputs. A 3-star warrior can receive relic custody that a recruit cannot. A 2-circle wizard can receive a ward-writ but not a gate-rewrite cap. The player-facing fiction is rank and training; the system-facing implementation is brokered authority.

Skills And Spells

Skills are martial or command actions:

• strike: basic weapon attack.
• guard: reduce incoming damage and protect one ally.
• shield-wall: requires 1 star and an allied legionary.
• counter: requires 2 stars; punish a missed melee attack.
• rally: requires 3 stars; restore morale and clear fear.
• order: requires appropriate writ; make an allied NPC act now.

Spells are prepared actions with fatigue or reagent costs:

• ember-dart: 1 circle; reliable ranged damage.
• detect-ward: 1 circle; reveals ward traits and mob intent.
• shield-bind: 2 circles; temporary guard bonus.
• mend-wound: 2 circles; stabilize or heal a wounded target.
• stabilize-gate: 3 circles; stops gate hazards or opens safe retreat.
• dome-shield: 4 circles; protects the whole party for one turn.

Forbidden or risky techniques:

• oath-echo: one-use inherited rite; strong effect, audit cost.
• demon-brand: hostile shortcut; should exist as a temptation, not an ordinary optimal play path.

Prepared spells should be visible in status. The first mission can grant only ember-dart, detect-ward, and shield-bind.

Fight Commands

Add combat commands:

• attack <mob>
• skill <name> [target]
• cast <spell> [target]
• guard [ally]
• order <ally> to <action>
• retreat
• status

Example:

[combat:signal_tower]> cast detect-ward wraith
The ward-wraith is bound to the broken tower sigil.
Intent: break shield next turn.

[combat:signal_tower]> order livia to dispel-sigil
Magister Livia spends the ward-writ grant. The sigil cracks.

[combat:signal_tower]> attack wraith
Your gladius bites through the fading ward. 5 damage.

Loot And Equipment

Loot should be sparse, inspectable, and tied to authority. The game should not become a pile of random nouns.

Item categories:

• supplies: torches, bandages, reagents, gate-stabilizer parts.
• equipment: gladius, shield, bow, focus ring, warded cloak.
• relics: eagle standard, sealed tablets, oath-bound cores.
• evidence: ash traces, broken sigil sketches, witness statements.
• trade goods: coin, salvage bronze, guild favors, ration chits.

Every loot entry should have at least one of these uses:

• opens a route,
• changes a combat choice,
• helps an actor,
• sells for a predictable value,
• acts as evidence in debrief,
• is dangerous custody with audit consequences.

Equipment can remain simple:

weapon: affects attack damage or skill unlocks
shield: affects guard and ally protection
focus: affects spell fatigue and ward inspection
cloak: affects stealth, ambush, or faction recognition
load: caps carried gear before fatigue penalties

Later equipment should support blueprint/artifact construction without turning the game into unbounded loot rolling. A construction job names a blueprint, materials, location/facility class, rank/star/circle gates, cost, expected duration, and output bounds. The service reserves materials and currency, validates the job, records it, and completes or releases it through the same transaction discipline used by markets. Item properties are derived from the base blueprint, material choices, crafter skill/rank, facility quality, and paid cost. Enchantment is a constrained post-process: object type, enchanter circle, lawful authority, and remaining enchantment slots determine valid results. Artifact-scale outputs include witness-sealed relic cases, warded cloaks, focus rings, route compasses, golem cores, and gate-stabilizer parts. This construction direction is grounded in Game Mechanics Prior Art, especially the Evil Islands and EVE Online notes.

Relics are not ordinary loot. They require custody authority, may be move-only, and should be visible in audit output. Dropping or trading a relic without the right witness should be a meaningful failure.

Buying, Selling, And Logistics

The shopkeeper should become a small economy service rather than ambient chat. The first version can be deterministic and local:

• buy <item> from <actor>
• sell <item> to <actor>
• quote <item> from <actor>
• trade <item> to <actor> for <item|favor>
• repair <item> at <actor>

Markets should have roles:

• quartermaster: sells supplies for ration chits, requires imperial standing;
• guild scout: sells route hints and contraband for coin or favors;
• temple annex: certifies relic custody and sells lawful wards;
• field engineer: repairs gate parts, golems, and damaged equipment.

Prices should be legible and bounded:

Maro offers ditch-route for 1 coin or scout-favor.
Quartermaster refuses focus-ring: requires wizard circle 1.
Iunia will certify eagle-standard only if oath-echo was not used.

Buying and selling maps naturally to capabilities. A shop can only sell what its actor is authorized to transfer; the player can only receive items or writs permitted by rank, faction standing, and mission state. Trade failures should name the blocked authority, not pretend the item is missing.

The regional market target is closer to a brokered order book than a single shop inventory. Market services should define market-eligible item classes, regional buy orders, sell orders, price/time priority, immediate matching when prices cross, expiry, fees, and ordered ledger receipts. Items that are not market-eligible still move through explicit custody, barter, witness, or quest flows. If several services own profile inventory, expedition cargo, outpost stock, or cloud-backed records, the market coordinator needs reserve/escrow, commit/release, stale-version rejection, idempotency keys, cancellation, retry, and crash-recovery behavior before any player-visible two-party exchange is treated as implemented. This market direction is grounded in Game Mechanics Prior Art, especially the EVE Online notes.

Randomization

Randomness should make repeated play feel alive without making QEMU coverage fragile. Use seeded mission variation, not hidden unbounded dice. The legal model remains deterministic and auditable: under the same seed and discovered facts, authority grants, denials, revocations, custody outcomes, and faction consequences must replay exactly.

The mission seed can choose:

• one of several mob placements,
• one optional route hazard,
• one mission complication,
• one faction demand,
• one shop inventory variant,
• one companion behavior pressure,
• one relic side effect,
• one enemy authority trick,
• one optional objective,
• one loot or writ modifier,
• one NPC rumor or personality line,
• one loot cache location,
• one debrief complication,
• a calendar state: season, day, weather/hazard class, seasonal resource table, festival/event hook, and routine variant.

The seed should be visible through debug or transcript mode, and smoke tests should pass a fixed seed through the manifest or mission setup:

Mission seed: 0x0000_aure_0009
Variant: ash-ghoul at ashen_road, focus-ring at under_vault

Combat randomness should be constrained by intent text. If an attack can miss, the player should see why through guard, morale, terrain, fatigue, or a mob trait. Critical swings should be optional flavor unless the seed is fixed.

Calendar variation should be similarly explicit. Four 28-day seasons are a reasonable initial model. Seasonal crops, forage, fish, shops, route hazards, and outpost production have bounded availability tables. Ordinary seasonal crops and fragile goods expire or degrade at season change unless the content declares them as multi-season. Festivals and military events can alter actor routines, witness availability, shop stock, quests, gifts, and affection-style standing records, but those effects must be ledger/profile facts rather than client-local counters. This calendar direction is grounded in Game Mechanics Prior Art, especially the Stardew Valley notes.

The implemented foundation keeps this deterministic for the smoke seed: generated mission content carries a fixed season, day, weather, hazard class, and bounded seasonal resource records for the proof categories. Status output prints that calendar state. Production per-run seed selection, event/festival records, actor routine changes, and gameplay consumption/expiry rules remain future work.

Seeded generation should produce explicit world artifacts, not invisible ambient randomness. The stable base game remains authored content: factions, major sites, named relics, law, core routes, capability interfaces, and proof missions. A production world can then select deterministic overlays from a WorldlineSeed:

• local room/map variants under authored region constraints;
• optional hazards, mob placement, loot caches, and rumor/debrief variants;
• seasonal resource tables, route closures, outpost production, and shop stock;
• festival or military-event schedules;
• bounded NPC routine variants and non-critical chatter hooks;
• regional market starting books, subject to service-owned order-book rules.

Every generated artifact should carry enough provenance to be replayed or rejected: content release id, worldline id, seed epoch, generator version, scope label, and bounded output size. Services should persist selected artifacts once admitted so later patches do not silently rewrite active worlds. Smoke runs keep using fixed authored selections until the generator itself has pure tests and a fixed-seed QEMU proof.

Chat And Room Memory

Room chat should become diegetic:

• room channels are command, scout, temple, and expedition channels,
• NPC process messages are radio/runner/magic-slate traffic,
• history replay is labeled as “recent room record” if intentionally shown,
• private messages require a separate cap or actor relation.

That turns the current chat persistence quirk into a feature.

Multiplayer

Multiplayer should be a first-class capability demonstration, not just several clients sharing one room. The current local foundation keeps per-player state keyed by live endpoint caller-session metadata and assigns service-local player labels such as player-1 for party commands. Those labels are not caller-chosen badges, global principal ids, or portable identity. The adventure service can add explicit shared expedition objects for parties, duels, trades, and contested sites when the single-service state model stops being sufficient.

Co-op mechanics:

• party create <name> creates a shared expedition with a leader cap.
• party invite <player> sends a join offer; accepting grants a party member cap with scoped verbs.
• party delegate <writ> to <player> gives another player a narrow authority, such as route access, relic carry, or squad order.
• assist <player> with <task> contributes a skill, spell, item, or witness action to another player’s command.
• sync-turn or mission turn barriers let QEMU scripts prove deterministic multi-client combat without racing terminal input.
• Split roles make co-op matter: scout reveals intents, wizard handles wards, warrior protects allies, witness certifies relic custody, quartermaster carries supplies.

Co-op failure should be interesting but bounded. A player can waste a shared turn, drop supplies, or revoke a delegated route, but cannot mutate another player’s private inventory without an accepted trade, custody transfer, or party rule.

Accepted trade and custody transfer must be service-mediated state transitions, not independent edits to two player save blobs. If one service owns both inventories, it should perform a single version-checked mutation and emit one ordered receipt. If ownership is split across profile, expedition, market, or cloud-backed stores, the Trade/Market/Expedition coordinator needs an escrow or saga protocol: reserve the item and consideration with idempotency keys, commit or release both sides, record an append-only ledger receipt, and make stale offers, cancellation, retry, and crash recovery explicit. User-owned Drive/Firebase save capsules cannot authorize these transfers; they may only back up the resulting private state after the authoritative receipt exists.

PvP mechanics should be opt-in and lawful in the fiction:

• duel challenge <player> creates a temporary arena with agreed rules.
• duel accept <player> grants a duel-combat cap scoped to the arena.
• spar <player> allows nonlethal training damage and skill practice.
• contest <site> lets factions compete over a route, relic, or witness record when the mission explicitly allows it.
• bounty mark <player> can exist only as a future policy-backed authority, never as ambient attack permission.

PvP must not mean “any client can attack any badge.” Harmful verbs require an arena, duel, faction-war, or bounty capability. The service should reject unauthorized attacks with a policy explanation:

No lawful conflict grants target marcus. Challenge a duel or enter the contested yard.

Useful rich PvP/co-op surfaces:

• shared threat tables where guarding an ally changes mob target intent;
• formation commands that require two or more players to hold compatible ranks;
• witness challenges where one party audits another party’s relic custody;
• contraband markets where guild standing helps one player but hurts temple reputation;
• route races where two parties can choose negotiation, sabotage, or legal contest depending on granted authorities;
• post-mission debriefs that record contribution, friendly fire, revocations, trades, and witness disputes.

Architecture:

• Expedition service owns shared party/site/combat state.
• Adventure keeps private player profile and inventory state.
• Chat carries room, party, duel, and faction channels.
• Trade or Market service owns two-party item/currency exchange, including reserve/escrow, commit/release, stale-offer cleanup, and replay-safe receipts.
• Audit records contested custody, PvP consent, and debrief evidence.

Near-term multiplayer should use live caller-session keys now and move to broker-granted service facets or service-created player objects once those are available. Manifest-issued receiver selectors are not a temporary Aurelian identity bridge; user-facing shell syntax must not choose or relabel another service identity. A useful QEMU proof uses two player objects or two distinct live caller sessions, one shared party, one delegated ward-writ, and one deterministic assist:

player1: party create tower
player1: party invite player2
player2: party accept tower
player1: delegate ward-writ to player2
player2: assist player1 with detect-ward
player1: attack ward-wraith

That proof is more valuable than adding network transport first because it exercises authority, shared state, and deterministic turn ordering locally.

Keep multiplayer scoped and desirable. Near-term multiplayer is cooperative expedition pressure: shared sites, dangerous relic custody requiring multiple witnesses, player deputies, faction-controlled regions, contested bounties, asynchronous rescue contracts, and public proof of heroic or criminal actions. Open ambient PvP is not the target; harmful verbs require explicit duel, contest, bounty, or faction-war authority.

MMO-scale open economies, broad player construction seasons, LLM-driven mission-critical NPCs, cross-instance federation, and worldline travel are deferred until the compact expedition loop works as a local and cooperative RPG.

Commit 335a9ee at 2026-04-28 22:22 UTC landed the first bounded Phase 12 foundation: the existing Adventure service now owns local party records for party create, party invite, party accept, party leave, party delegate, and assist. Party membership, pending invites, delegated ward-writ, and assist records are deterministic service state keyed by service-local player labels derived from caller-session keys, with transitions routed through the unit-tested adventure-content party state. The initial assist <player> with detect-ward path requires party membership and a matching delegated ward-writ; it does not transfer items, currency, or private inventory authority. A real one-client cap assertion covers the typed party surface, while the two-client proof remains open until the manifest and launcher/session APIs can run two real Adventure clients with distinct live caller-session keys without faking them inside one process.

Commit ac49375 at 2026-04-29 06:43 UTC landed the next bounded Phase 12 transfer foundation and keeps transfer state inside the existing Adventure service. The new typed Adventure.transfer(item, player) path supports transfer <item> to <player> for physical items only, derives both service-local player labels from live caller-session keys, requires shared party membership, refuses relic custody such as eagle-standard, and mutates source/target inventories atomically through unit-tested adventure-content transfer logic. The scenario process asserts one-client refusal paths without synthesizing a second session. Currency escrow, market-scale two-party exchange, and successful two-client QEMU transfer proof remain open.

Parallel Universes And Cross-Instance Worlds

Parallel universes fit Aurelian better as sovereign worldlines than as one shared mutable map. Each capOS instance can host one or more worldline services that use the same content release but different WorldlineSeed values, calendar epochs, market starts, event schedules, and generated regional overlays. Players should experience those worlds as alternate Aurelian frontiers, while the authority model treats each worldline as its own shard with its own ledger, market, expedition, and profile policy.

This is feasible, but only after the local authority model is solid. Raw capability slots, endpoint generations, session ids, and local player labels cannot be portable authority across kernels. Cross-instance play needs a federation gateway that presents narrow local facade caps backed by remote protocol messages:

• WorldlineDirectory: lists known remote worlds by content release, worldline id, endpoint, policy, and current ledger head.
• WorldlineVisit: grants read/observe/chat/travel-preview authority for a remote site without importing inventory or mutation rights.
• WorldlineExpedition: creates a bounded cross-world expedition object with explicit participants, allowed verbs, timeout, and home-world settlement rules.
• WorldlineTransfer: coordinates item, currency, custody, or profile-state movement through reserve/escrow, commit/release, replay-safe receipts, and content-version checks.
• WorldlineAudit: verifies remote receipts, ledger-head continuity, content hashes, generated-artifact provenance, and policy compatibility.

The game should support several integration levels, each with a different authority cost:

• Echo view: a player can inspect another worldline’s public map state, rumors, market summaries, and public history. This is read-only and can land first.
• Envoy visit: the local world creates a temporary projected character in a remote worldline. The projection may chat, observe, or perform explicitly granted low-risk actions, but cannot spend home inventory directly.
• Expedition bridge: two worlds run a shared mission instance with a fixed seed and a coordinator receipt. Contributions are recorded in both ledgers only after commit.
• Trade or custody transfer: ordinary goods, relics, currencies, or reputation effects move only through a transfer coordinator. Partial failure releases reservations; retries are idempotent.
• Worldline migration: a profile moves or copies into another worldline under policy. Public achievements and custody claims are imported as verifiable receipts, not trusted client save blobs.

Parallel universes make seeded generation more important. If every worldline is the same authored graph with the same resources and routines, federation is mostly remote chat. Meaningful worldline differences should come from bounded seeded overlays: seasonal economies, market starts, event schedules, route hazards, outpost outputs, NPC routines, optional dungeons, and regional map variants. The generator must not mint authority by accident. It can choose that guild_iron_mine is closed in one worldline and open in another, but the resulting travel, market, custody, and reward effects still flow through the same service-owned capability and ledger paths.

Cross-world compatibility rules:

• A worldline advertises a content release id and generator version. Peers may reject incompatible worlds or fall back to echo-only mode.
• Generated artifacts are referenced by stable ids and provenance hashes, not by trusting remote prose.
• Remote markets expose authenticated order/receipt views; local UI hints are not authority.
• Cross-world transfers name both ledger heads and both worldline ids in the receipt, so replay into a different universe fails closed.
• Faction standing, rank, and contributor rewards should import as witnessed claims with local policy gates. A remote honor does not automatically grant a local writ.
• Clock/calendar drift is part of the design: worlds may have different seasons, festivals, or wars. Shared expeditions must pin an event epoch or name which world’s calendar controls the mission.
• Failure modes are ordinary gameplay states: remote world unavailable, receipt stale, policy mismatch, content hash unknown, or escrow timeout. Each should have a deterministic denial path.

Near-term proof should not attempt full network-transparent play. A useful first slice can run two worldline services on one capOS instance with different fixed seeds and prove echo view plus a denied transfer:

worldline list
worldline inspect aurelian-mirror
worldline echo aurelian-mirror fort_aurelian
worldline transfer eagle-standard to aurelian-mirror

The expected result is that public state can be observed with content/seed metadata, while relic transfer is rejected until custody escrow, remote policy, and dual-ledger receipts exist.

Capability Mapping

The setting should teach capability ideas through play:

The player does not need to see cap IDs. The game text should make authority concrete: “You cannot open the southern ward; your writ names only the tower gate.”

Service Architecture

Target process split:

flowchart TD
    Shell[capos-shell] --> Client[adventure command client]
    Client --> Adventure[Adventure service]
    Client --> Chat[Chat service]
    Adventure --> Mission[Mission state service]
    Adventure --> Audit[Audit or witness service]
    NPC1[centurion process] --> Chat
    NPC2[scout process] --> Chat
    NPC3[temple witness process] --> Chat
    NPC1 --> Adventure
    NPC2 --> Adventure
    NPC3 --> Adventure

Near-term implementation can keep one adventure-server process and separate NPC processes that only hold console and chat, matching the current system-adventure.cue shape. NPCs that affect world state should initially do so indirectly through player-visible offers and chat events. Direct NPC calls into Adventure require session-bound service facets such as AdventureNpc, or an equivalent broker-granted authority that cannot mutate unrelated mission state. Receiver-selector compatibility grants are not NPC mutation authority.

Later, mission state, actor AI, and audit/witness behavior can split into separate services.

Player, World, And Game Persistence

Persistence should be explicit service state, not kernel process checkpoint/restore. The adventure game needs several kinds of state with different durability rules:

• Session state: foreground client state, prompt mode, transient command context, and chat cursors. This is per client and may disappear when the client exits.
• Expedition state: current site, active mobs, hp/fatigue, temporary effects, party membership, pending invites, turn ordering, and in-progress objective state. It is resumable only when the player explicitly resumes an expedition. Ordinary run adventure-client should start from the current profile but not silently continue a half-finished mission.
• Profile state: player id, display handle, rank marks, warrior stars, wizard circles, faction standing, cosmetics, contributor badges, title choices, and settings. This is durable player data and must survive client exit; once a durable store exists it should survive reboot.
• Ledger state: append-only mission facts, debrief records, relic custody, forbidden-rite use, witness certifications, market/trade receipts, reward mints, and revocations. This is the audit source for profile mutations and should be harder to rewrite than profile summary fields.
• World/public state: server-authoritative shared world data: persistent room history, public faction standing and consequences, quest-board state, market stock and prices, contested-site outcomes, ledger-derived public history, and shared campaign events. This is owned by game services, not by any one client, and is separate from private profile inventory. Smoke transcripts exercise a bounded slice of this state; production game-world instances grow it under capacity policy and shard boundaries rather than a fixed cap.
• Content state: mission definitions, generated content blobs, aliases, dialogue, map graph, and validation metadata. This is versioned read-only content selected by content hash or release id, not player-mutable state.
• User-owned backup state: encrypted save capsules stored through a browser session in the user’s own Google Drive app data folder or Firebase-backed user document space. This is private backup/sync state, not an authoritative source for shared world facts, rewards, or multiplayer outcomes.

Internal service split:

flowchart TD
    Client[Adventure client] --> Adventure[Adventure service]
    Adventure --> Content[AdventureContentCatalog]
    Adventure --> Profile[AdventureProfileService]
    Adventure --> Expedition[AdventureExpeditionService]
    Adventure --> Ledger[AdventureLedger]
    Profile --> Save[AdventureSaveStore]
    Expedition --> Save
    Ledger --> Save
    Save --> Store[Store or CloudGameStore]
    Save --> Vault[UserOwnedSaveVault]

• AdventureContentCatalog exposes validated read-only mission content by content hash or release id and reports the generator/schema version used to build it.
• AdventureProfileService owns durable per-player profile summaries. The current pre-ledger substrate may expose direct bounded summary mutation for host-testable save/load behavior, but final reward, title, rank, faction, cosmetic, badge, and similar profile application must be ledger-backed once AdventureLedger exists.
• AdventureExpeditionService owns active mission/world instances. It can keep short-lived expeditions in memory, but explicit resume requires a checkpoint written through AdventureSaveStore.
• AdventureLedger is append-only from ordinary game clients. Correction and revocation require separate witness/admin authority and must leave a record rather than rewriting history.
• AdventureSaveStore serializes bounded Cap’n Proto save records to whichever backing service it was granted. It hides whether the backing is RAM, local disk Store/Namespace, or a cloud bridge.
• CloudGameStore is an optional bridge service, not a replacement for capOS storage semantics. It exposes the same save/load/append operations as the local store adapter and should be granted only to the profile, expedition, and ledger services that need it.
• UserOwnedSaveVault is a browser-mediated backup target. The browser receives an encrypted, signed save capsule and writes it using user-granted Drive or Firebase authority. Encryption keys follow the storage domain: local capOS storage uses local capOS-host key material, while GCP-backed game-world data uses Cloud KMS envelope encryption with a per-world or per-shard KEK wrapping service-owned DEKs. capOS and the adventure service do not receive the user’s OAuth access token, Firebase refresh token, Drive file IDs beyond opaque handles, or provider credentials.

Recommended rollout:

1. Volatile baseline: keep current in-memory state keyed by the live endpoint caller-session scoped ref plus epoch, but define the profile, expedition, ledger, and content records as bounded structs and add host tests for encode/decode and migration rules. Normal shell launch/grant commands now omit legacy badge and receiver-selector syntax; explicit selectors are low-level compatibility or hostile-path fixtures, not the state identity model.
2. Local store baseline: use RAM-backed then disk-backed Store/Namespace caps to prove profile save/load, explicit expedition checkpoint/resume, and ledger append/replay. This is the offline and QEMU proof path.
3. GCP-backed bridge: run a narrow CloudGameStore bridge outside capOS or as a capOS service once networking is available. A practical GCP deployment uses Cloud Run for the bridge endpoint, Firestore Native mode for mutable profile/index documents and transactional updates, Cloud Storage with object versioning/lifecycle policy for immutable snapshots and evidence blobs, and Secret Manager for bridge-side service credentials. capOS clients still see only the CloudGameStore capability.
4. User-owned browser vault: for private player data, a web terminal or browser companion can store encrypted save capsules in Google Drive appDataFolder or a Firebase user document. This is useful before capOS has durable local disk or direct provider SDK support. It must be treated as user-controlled transport for game-world encrypted data: the user can delete, withhold, duplicate, or roll back blobs, but cannot decrypt or forge accepted state without the relevant local capOS key or game-world KMS authority. On restore, the game verifies signatures, schema/content hashes, profile id, monotonic capsule version, previous capsule hash, and policy bounds before accepting any state; decrypted ledger records still validate their own previous-record hash chains.
5. Hybrid sync: local Store remains the source for QEMU/offline proof paths, while CloudGameStore replicates selected profile/ledger objects. The sync boundary must be explicit: profile summaries may be overwritten through a checked version, ledger records append, and expedition checkpoints resolve conflicts by rejecting stale writes rather than merging combat state.

Minimum save record set:

AdventureProfile {
  profile_id
  display_handle
  version
  ranks
  warrior_stars
  wizard_circles
  faction_standing
  cosmetics
  contributor_badges
  settings
  updated_at
}

AdventureExpeditionCheckpoint {
  expedition_id
  profile_id
  content_hash
  checkpoint_version
  site_id
  objective_state
  player_state
  party_state
  mob_state
  pending_events
  saved_at
}

AdventureLedgerRecord {
  record_id
  profile_id
  expedition_id
  content_hash
  kind
  previous_record_hash
  payload
  witness
  created_at
  revoked_by
}

User-owned save capsules wrap those records rather than replacing them:

UserSaveCapsule {
  schema_version
  capsule_version
  profile_id
  device_id
  content_hash
  migration_policy
  record_kind
  record_version
  previous_capsule_hash
  plaintext_hash
  ciphertext
  aead_algorithm
  signature_algorithm
  signer_public_key_id
  signature
  created_at
}

Capsule encryption follows the same storage-domain rule as the backing store. When state is stored locally on a capOS host, the encryption key is local capOS-host key material and local backup/restore needs an explicit local key recovery story. When state is stored in GCP services, Cloud KMS is the key-encrypting-key service: it wraps or unwraps a capsule DEK, while the game-world service decrypts and validates capsule plaintext internally using the unwrapped DEK as service authority, modeled as a SymmetricKey capability. The browser may transport ciphertext, wrapped DEKs, and opaque Drive/Firebase handles, but it should not receive a plaintext DEK, SymmetricKey cap, KeySource cap, KMS decrypt/unwrap grant, or provider-independent plaintext authority unless a later explicit user-managed key export design adds that mode. For GCP-backed worlds, access to unwrap and use the DEK is game-world service authority mediated by KMS/IAM, not ownership of the Drive or Firebase blob alone.

For the GCP path, each game-world instance or shard gets its own Cloud KMS key ring and symmetric CryptoKey KEK. Runtime grants are scoped to the CryptoKey where possible: encrypt-only writers use roles/cloudkms.cryptoKeyEncrypter to wrap new DEKs, restore/migration readers use roles/cloudkms.cryptoKeyDecrypter to unwrap existing DEKs, and only the small game-world service that must do both uses roles/cloudkms.cryptoKeyEncrypterDecrypter. Rotation affects future DEK wrapping but does not re-encrypt existing capsules or retire old key versions. Re-encryption or rewrapping is a managed service operation: decrypt and validate the capsule inside the game-world service, then write a new capsule with a new DEK or a DEK rewrapped by the current primary KEK version. Old versions stay enabled until no accepted wrapped DEK depends on them. Retiring a world removes decrypt IAM first, may disable key versions to make protected capsules inaccessible, and only schedules destruction after audit/recovery decisions because completed key version destruction is irreversible.

Every persisted record needs a schema version, content hash or release id, size limit, and migration rule. Save/load must fail closed when the content hash is unknown, the record exceeds bounds, a capsule or ledger hash chain does not match, or the caller lacks the profile/expedition authority.

Do not use user-owned Drive/Firebase blobs as authority for public state:

• contributor rewards still require AdventureLedger witness records;
• multiplayer outcomes and market trades still require service-side validation;
• public room history and shared world events should be stored by the game service or cloud bridge, not accepted from a user’s private backup;
• rollback of a private backup may restore local profile cosmetics or an explicit expedition checkpoint, but it must not erase append-only public ledger facts.

Interface Sequencing

Do not add new gameplay verbs only as ad hoc client text. Every verb that changes world state needs a typed route before it is accepted as implemented.

For Phase 1 verbs, update these surfaces together:

• schema/capos.capnp: add methods or typed command records for inspect, use, give, ask, order, seal, status, and explicit authority verbs including request, accept, delegate, and revoke.
• tools/generated/ and canonical generated bindings through the existing generated-code workflow.
• demos/capos-chat: add request encoders, result decoders, and DTOs for the new adventure methods.
• demos/adventure-server: validate state, authority, bounds, and failure text in server handlers.
• demos/adventure-client: keep parsing thin; convert user text to typed calls rather than duplicating game rules.
• tools/qemu-shell-smoke.sh: assert one success path and one failure path for each new state-changing method.

The future CommandSession interface can replace the text adapter, but it is not a reason to add stringly world mutation in the interim.

Resource Bounds And Determinism

Two distinct bound regimes apply: the deterministic QEMU smoke proof, which must stay small and reproducible, and the production game-world instance, which is bounded by service capacity, shard policy, and quotas rather than a single fixed cap. The numeric limits below are the smoke-instance defaults; production tuning belongs to the game-world deployment runbook and grows with profile/ledger/expedition substrate, multiplayer authority, and persistent world state.

Smoke-instance and per-shard rules:

• Per-instance MAX_PLAYERS stays explicit; every per-player map entry is removed on leave or process teardown.
• Cap per-player inventory entries, writs, relics, marks, evidence records, active effects, and remembered chat cursors.
• Cap per-site mobs, items, active wards, actors, and pending events.
• Cap combat transcript lines per turn and reject oversized action text before semantic parsing.
• Smoke transcripts use fixed encounter scripts. Production play may seed variation from mission state, but transcript-critical paths must still force a stable seed.
• Keep multiplayer parties, duels, trades, pending invites, and contested-site records bounded per mission/shard with explicit overflow behavior, not silent drop.
• Chat history must either be cursor-based per client or printed under an explicit “recent room record” header with a bounded line count for live views; persistent chat history may grow under retention policy in ledger/world-state services.
• The current StdIO adapter may accept 256-byte command lines, but typed ids inside service calls remain 64-byte ASCII ids unless a reviewed schema/runtime change raises that limit.
• Keep free-form text fields separate from ids: say text and future rest-of-line command text may use the command-line limit, while object ids, actor ids, mob ids, writ ids, directions, spell names, and skill names use the id limit.
• Generated mission content must define explicit bounds for titles, descriptions, lead text, aliases, dialogue, and debrief lines, and branches that check in generated content need a freshness check so generated Rust blobs cannot drift from source mission data.

Smoke-instance suggested limits (production shards may raise these under capacity policy, but transcript-critical paths must run inside these bounds):

players: 64
inventory entries per player: 16
writs per player: 8
evidence records per player: 16
active effects per player: 8
mobs per site: 8
party members: 4
pending trades per player: 4
pending invites per player: 4
chat history per room: 16 lines
command-line bytes: 256
typed id bytes: 64
room/site title bytes: 80
description bytes: 320
lead/failure-hint bytes: 160
actor dialogue/debrief line bytes: 320

Command Surface

The current StdIO parser can grow the first mission quickly, but the target should be the structured command session described in interactive-command-surface-proposal.md.

Initial text commands:

• look
• go <direction>
• inspect <thing>
• take <thing>
• use <thing>
• give <thing> to <actor>
• ask <actor> about <topic>
• request <writ>
• accept <writ>
• delegate <writ> to <actor>
• revoke <writ>
• order <actor> to <task>
• seal <target>
• inventory
• status
• say <text>
• quote <item> from <actor>
• buy <item> from <actor>
• sell <item> to <actor>
• trade <item> to <actor> for <item|favor>
• repair <item> at <actor>
• party <create|invite|accept|leave|delegate>
• assist <player> with <task>
• duel <challenge|accept|yield>
• spar <player>
• contest <site>
• quit

Dynamic completions should come from room state:

• exits for go,
• visible items and held writs for inspect and use,
• present actors for ask and give,
• quoted shop inventory for buy and sell,
• party members and pending invites for party and assist,
• mission targets for seal.

Rich Browser Client

A later browser client should be a real game presentation layer: pixel-art locations, animated characters, inventory and authority panels, combat affordance buttons, event feeds, and chat surfaces. It should not be a terminal emulator with decorative art around StdIO.

The presentation model should be a 2D tilemap, not prose-only room cards. World data sent to the browser can include maps, tilesets, tile layers, object layers, collision/interaction zones, spawn points, actor paths, region/outpost markers, and event triggers. Tiled JSON is a plausible authoring/export format if the content validator rejects oversized maps, missing tiles, unknown layer types, invalid object references, and presentation data that tries to carry authority. PixiJS plus @pixi/tilemap is a reasonable first rendering candidate because it targets WebGL 2D tile rendering with a canvas fallback. That renderer choice must stay client-side; the game service remains the owner of authoritative location, collision, interaction, market, custody, and combat state.

That client can bypass adventure-client. The text client remains valuable for QEMU proofs, scripted transcripts, and compatibility, but the browser UI should talk to the adventure and chat services through WebShellGateway-held session authority:

Browser pixel-art UI
  -> WebShellGateway / web shell capability-call proxy
  -> session-scoped AdventurePlayer and ChatParticipant caps
  -> adventure-server and chat-server

The browser does not hold capOS capabilities directly. It holds opaque web-session handles and sends typed UI actions such as movement, target selection, inventory use, delegation, order, spell, skill, and chat requests. The gateway maps those requests onto the real session-scoped capabilities and returns structured view state or event records for rendering. Raw capOS CapIds, badge selectors, game-world keys, provider credentials, broad network authority, and shell spawn authority must not cross into browser JavaScript.

For the purpose-built adventure UI, a narrow AdventurePlayer / ChatParticipant surface is a better primary ABI than generic terminal text:

AdventurePlayer.look()
AdventurePlayer.go(direction)
AdventurePlayer.status()
AdventurePlayer.inventory()
AdventurePlayer.useItem(item, target)
AdventurePlayer.order(actor, task)
AdventurePlayer.cast(spell, target)
AdventurePlayer.skill(skill, target)
AdventurePlayer.delegate(writ, actor)
AdventurePlayer.pollEvents(cursor, maxEvents)

ChatParticipant.say(text)
ChatParticipant.history(cursor, maxLines)

CommandSession can still exist for terminal-like front ends, command palettes, automation, and compatibility adapters. It is not required for a custom pixel-art client whose UI already knows it is presenting the adventure game. The non-negotiable boundary is that browser presentation never becomes authority. Every action still flows through typed game capabilities, and the server rejects invalid location, stale state, missing authority, bad custody, combat restrictions, and oversized input.

This belongs well after the current game-depth phases. It depends on WebShellGateway authentication/origin policy and teardown, session-bound adventure/chat identity, persistent profile/checkpoint semantics, and a stable core game loop. Asset manifests for sprites, portraits, tiles, VFX, UI sounds, and animation ids should be explicit data. Asset presence or selection must not grant game authority, and missing assets should fail as presentation errors rather than mutating game state.

The browser harness should verify more than successful loading. It should drive one deterministic mission through UI actions and check tilemap layer order, actor placement, viewport/camera bounds, collision affordances, event-feed updates, logout/tab-close teardown, and rejection of browser-side attempts to mutate authoritative state without the typed gateway call.

QEMU Proof Path

Keep a deterministic smoke path similar to make run-adventure, but make it prove game mechanics:

setup/login
run adventure-client
status
ask centurion about mission
request ward-writ
go gate
use ward-writ
go tower
inspect standard
recover eagle-standard
ask legionary about ward
give scout-marker to scout
go under-vault
seal gate
inventory
quit
exit

Assertions should check:

• launch grants remain explicit,
• no password leaks into logs,
• invalid action returns a specific failure,
• authority grant/delegation uses explicit verbs rather than take,
• item use changes world state,
• NPC process reacts to at least one player action,
• mission completion records an audit/witness line,
• replayed chat is either suppressed or labeled as history,
• at least one canonical-id suggestion for a near-miss command,
• one shop quote or rejected trade explains the authority or price gate,
• a fixed mission seed prints stable variant and calendar metadata once randomization lands,
• a two-client co-op proof can delegate one writ or assist one action without leaking private inventory authority.

Current implemented proof coverage is intentionally narrower than the eventual target game, but it now follows the Aurelian mission path. make run-adventure keeps the shell-driven adventure-client transcript focused on representative interactive behavior: typed inspect, status, attack, skill, cast, give, ask, order, request, accept, and delegate calls; room-view mission, lead, actor, mob, writ, item, and canonical exit context; categorized Items, Writs, Relics, Marks, and Evidence output; a rejected invalid inspect input; canonical-id suggestions for near-miss ward and wraith inputs; Maro route evidence on ashen_road; a separate NPC process reaction; a failed attack against a warded mob; delegated order livia to dispel-sigil exposing a ward; a resolved Livia actor alias with an improved task hint; repeated detect-ward idempotence on an already exposed ward; ember-dart spell damage; a 2-star warrior strike; and eagle-standard recovery.

The complex custody path is covered by adventure-scenario-test, a real capOS userspace process with only Console and Adventure caps. It calls AdventureClient methods under QEMU and asserts initial categories, under_vault denial before temple-seal, pre-recovery Iunia denial, ward-writ route authority setup, ward-wraith defeat, relic recovery, non-droppable relic behavior, missing-location custody denial, missing ward-writ authority denial, unsafe-route witness refusal, survivor evacuation, gate sealing, witness-certified temple-seal custody, final evidence tokens, and under_vault access after custody.

The test strategy should stay split by risk. Pure deterministic game logic should live in ordinary Rust unit tests where possible: calendar rollover, seasonal availability, market matching, escrow state machines, blueprint validation, artifact property derivation, enchantment limits, route constraints, and agent quota accounting. Cross-service gameplay scenarios should use a real Rust userspace test client process that calls game caps under QEMU, as adventure-scenario-test already does for custody. The shell-driven adventure-client transcript remains the basic command/client proof for parser behavior, rendering, representative typed calls, and smoke-path integration; it should not become the only coverage for complex market, construction, economy, or agent-NPC state machines.

Implementation Plan

Phase 1: Player-Visible Mission Substrate

• Implemented so far:
  • typed inspect, use, status, attack, skill, cast, and guard methods across schema, generated bindings, client wrappers, server handlers, terminal parser, and QEMU transcript assertions,
  • typed give, ask, order, seal, request, accept, delegate, and revoke methods across the same schema/client/server/parser/proof path,
  • explicit result text for failed and successful go, take, and drop actions,
  • compact player combat stats in status: hp, guard, fatigue, warrior stars, wizard circles, prepared spells, and active mobs,
  • one deterministic ward-wraith encounter with a warded-mob failure path, spell reveal, spell damage, martial skill damage, guard effect, and mob defeat,
  • one explicit objective and completion condition tied to ward-wraith defeat,
  • minimal per-player authority state for ward-writ request, acceptance, delegation, revocation, and gate sealing,
  • bounded per-player evidence/effect storage surfaced in status,
  • replayed room chat labeled as history for later room joins,
  • bounded object-id validation for typed object inputs,
  • server-side canonical id normalization for common casing and title aliases, plus bounded near-miss suggestions for the current mission ids,
  • typed AdventureRoomView mission, lead, actor, mob, writ, item, and canonical exit context rendered by look,
  • structured status and inventory output split into survival, location, mission, physical items, writs, relic custody, marks, evidence, effects, and lead,
  • idempotent repeated spell behavior in the interactive transcript,
  • a dedicated adventure-scenario-test userspace process that calls the Adventure cap directly to prove relic custody denial, witness refusal, temple-seal certification, categorized evidence, and under_vault access.
• Current playable slice: the Aurelian gate-fort mission now comes from demos/adventure-content/content/prototype.cue, with checked-in generated Rust output consumed by the server and verified by make generated-code-check. State-changing behavior remains in Rust handlers, and make run-adventure proves the interactive eagle-standard recovery and replay-history path, while adventure-scenario-test proves survivor, gate-seal, and temple custody outcomes through real Adventure cap calls.
• Typed relic recovery: recover eagle-standard is the dedicated custody verb, with take and drop reserved for physical items.
• Local party foundation: Adventure owns the first deterministic party state for service-local player labels, pending invites, scoped ward-writ delegation, and detect-ward assist records. PvP consent, transfer escrow, and the two-client QEMU proof remain future work.
• Physical-item transfer foundation: Adventure.transfer performs same-party local item mutation for ordinary inventory items and leaves currency escrow, cross-service trade, relic custody transfer, and successful two-client proof as future work.

Phase 2: Imperial Frontier Mission

• Replace current four-room content with the Aurelian gate-fort mission. Complete.
• Preserve objective/lead text in look and status, plus canonical-id suggestions for common near-miss commands.
• Add typed inventory categories: items, writs, relics, evidence, marks. Complete for player-facing status and inventory output.
• Add at least three actor processes with distinct chat/personality behavior; keep them chat-only unless explicit scoped Adventure grants and tests land in the same slice.
• Add one route requiring a capability-style permission.
• Add one objective with two acceptable outcomes.
• Add one narrative debrief that records rank, standing, evidence, and audit consequences.

Phase 3: Persistent Profile And Ledger Substrate

• Define AdventureProfile, AdventureExpeditionCheckpoint, and AdventureLedgerRecord structs with schema versions, content hashes, size limits, and host migration tests.
• Add AdventureProfileService, AdventureExpeditionService, AdventureLedger, and AdventureSaveStore interfaces before persisting profile or world state in ad hoc server maps.
• Prove a local baseline first: profile save/load, ledger append/replay, and explicit expedition checkpoint/resume through RAM-backed or disk-backed Store/Namespace.
• Keep ordinary client launch fresh by default; require an explicit resume command or profile option before loading an active expedition checkpoint.
• Add one rejected stale-checkpoint write and one rejected wrong-profile load to QEMU or host-level proof coverage.

Phase 4: User-Owned Browser Save Vault

• Define UserSaveCapsule and browser transport semantics for private encrypted profile, settings, and explicit expedition checkpoint backups.
• Use Google Drive appDataFolder or Firebase user documents as opaque capsule transports only; browser-held OAuth/Firebase tokens must not enter capOS game services.
• Add tamper, wrong-profile, stale-version, replay, unknown-content, and oversized-capsule rejection tests before real provider adapters.
• Keep public world state, multiplayer outcomes, reward witnesses, and market receipts out of user-owned blobs.

Phase 5: Compact Authority-RPG Loop

The next implementation phase should build on the pure targeted-combat foundation from commit f149119, not reopen broad calendar, market, construction, agent-NPC, federation, or worldline systems. The goal is one excellent expedition loop where authority is RPG power: choose writs and companions, enter a dangerous site, discover authority conflict, fight or negotiate under pressure, delegate or revoke power, extract, and gain reach for future missions.

• Generate combat profiles from CUE for current mobs and validate malformed zones, damage kinds, alert groups, recognition thresholds, and stealth references through make generated-code-check.
• Integrate generated combat profiles into adventure-server so inspected attacks use deterministic zone damage, fatigue, interruption, recognition, and alert helpers. Clients must not submit computed damage.
• Extend parser/proof coverage only as needed for unambiguous authority-RPG commands: attack <mob> [zone] [with <weapon>], cast <spell> at <mob> [zone], and at least one authority-combat verb such as inspect seal, challenge authority, or expose forgery.
• Add one authority-attacking enemy behavior to the existing expedition: a forged route/custody claim, stolen custody token, seal conflict, corrupt revocation, or old-law wraith claim that can be inspected, exposed, bound, or revoked.
• Treat writs as loot. Add one fixed-seed or authored writ modifier with a meaningful drawback; print issuer, scope, expiry, delegation rules, revocation conditions, modifier, and drawback in inspect/status output, and enforce the drawback in service logic.
• Add one delegation-buildcraft proof using an existing companion. A trait such as loyalty, competence, fear, reputation, or doctrine should change how a delegated ward-writ or custody authority behaves and explain the cause.
• Add one reach-based debrief unlock, such as Archive evidence verification, Temple vault custody upgrade, Signal tower remote revocation, or appointing one field deputy. This should unlock a future verb or jurisdiction, not generic damage or health.
• Keep denial rewarding: at least one new authority denial should reveal a lead about hidden jurisdiction, forged authority, missing witness, rival claim, or alternate route.
• Prove the slice with pure Rust tests for deterministic rules and one adventure-scenario-test path covering inspected targeted attack, authority threat/lead, writ drawback, delegation consequence, and reach unlock. The shell transcript should remain representative parser and smoke coverage.

Broad systems remain deliberately demoted until this loop is strong: calendar/season gameplay, regional market order books, construction jobs, artifact/enchantment production, optional agent NPCs, MMO/open economy work, federation, and worldlines should not be treated as next local sequencing truth for implementation agents.

Phase 6: Structured Command Session

• Move from app-owned StdIO parsing to CommandSession.
• Expose dynamic command metadata and completions.
• Keep a text adapter for QEMU scripts.

Phase 7: Multiplayer Authority Proof

• Do not start this phase until Adventure and chat authority use session-bound caller identity, or future broker-granted service facets, rather than player receiver-selector identity. The first bounded slices key local player labels from live caller-session metadata.
• Add local multi-client party state keyed by service-created player objects, with explicit invite, accept, leave, and delegation commands.
• Add one deterministic co-op combat or ward puzzle where one player assists another without receiving unrelated inventory authority.
• Add one opt-in duel or sparring proof with scoped harmful authority and a rejected unauthorized attack path.
• Add bounded trade offers for ordinary loot and reject relic transfers unless custody authority permits them. The proof must show the transfer coordinator cannot duplicate, lose, or partially transfer an item when offers go stale, cancellation races with acceptance, or a retry repeats the same request.
• Extend QEMU scripting to drive two clients or two command sessions through a stable multiplayer transcript.

Future Follow-Up: Golems, Gates, And Infrastructure

Golems should be imperial magotechnical infrastructure before they are enemies. They fit the setting as labor frames, cargo haulers, bridge-builders, sentries, field repair units, siege engines, and rare battlefield assets. Model each golem as a body, a bound core, and an energy source: the body defines role, the core defines identity and obedience, and the energy source defines endurance.

Initial golem types:

• cargo-golem: moves sealed supplies or heavy relics only when granted a matching route authority.
• ward-golem: guards a shrine, vault, or gate and recognizes proof tokens rather than passwords.
• siege-golem: breaks barriers but requires multiple grants, such as engineer approval plus energy access.
• field-repair-golem: restores damaged ward anchors when supplied with materials and repair authority.
• corrupted-golem: obeys malformed or stale authority, making revocation and audit behavior visible in play.

A golem should not become ordinary inventory. The player receives scoped command authority over it: inspect, wake, route, repair, bind, delegate, audit, or revoke. A useful rule of thumb: order cargo-golem north-gate succeeds only when the player holds both cargo-command and north-gate-route.

Gates and portals should be imperial route infrastructure: roads made executable. They move authority, troops, messengers, and supplies across the frontier. Standing at a gate is not enough; use requires a physical anchor plus a valid writ, seal, route token, ward key, or alignment state.

Gate components:

• gate-anchor: fixed legal endpoint.
• route-writ: temporary authority to open one path.
• ward-key: faction or office authorization.
• stabilizer: consumable or repairable part that bounds usage.
• gate-log: inspectable audit trail for deterministic investigation evidence.

Gate constraints should create missions rather than decoration:

• gates open only between known anchors,
• heavy constructs require freight routes rather than personal routes,
• damaged gates can misroute, refuse cargo, or leak hostile entities,
• emergency gates can open one-way and revoke the route after use.

Follow-up mission candidates:

• Gate repair: recover a stabilizer, prove engineer authority, order a repair golem, and open a bounded evacuation route.
• Golem command: delegate a narrow task to a ward golem after presenting the correct seal.
• Logistics: move medicine, grain, or signal crystals through gate routes with cargo-size and route-authority limits.
• Investigation: inspect gate logs, compare seals, and identify which faction abused or forged route authority.
• Siege: choose between spending rare siege-golem command, negotiating gate access, or repairing an old military road.
• Containment: seal a corrupted portal while wizard-circle spells stabilize the breach and warrior-star formations defend the site.

Typed verb candidates for these later slices include bind, route, repair, charge, open-gate, seal-gate, attune, stabilize, trace-route, and audit-gate. They should remain scoped and revocable, and status output should expose active seals, bound routes, charged spells, wounded formation members, unstable wards, and delegated golem tasks.

Open Questions

• Should actor NPCs call the adventure service directly, or should they only communicate through chat in the first interesting version?
• How much randomized event timing can be allowed in production play before QEMU transcript coverage becomes brittle, given the smoke path runs under a fixed seed?
• Should shops and trades live inside Adventure at first, or split into a Market service once two-party trade exists?
• Should parties be mission-local objects, profile-level groups, or future session broker grants?
• What is the minimum PvP consent record that is useful for the game without overbuilding policy after the profile/ledger substrate exists?
• How are game-world shards/instances scoped: one shared world, one per campaign, one per party, or one per deployment? This determines whether faction standing, ledger history, and market state are global or per-shard.
• Where does the boundary sit between server-authoritative public history (visible to all players in a shard) and per-profile audit records that remain private even within the same shard?
• After the echo-only worldline proof, should the next federation slice be envoy visits, expedition bridges, market/custody transfer, or profile migration?
• What retention/archival policy applies to ledger records, debrief evidence, and chat history once the game runs long enough to accumulate them?

Follow-Up Proposal

After the Aurelian adventure design is implemented well enough to support stable profiles, ranks, evidence, debriefs, cosmetic items, and deterministic proof coverage, the game can grow a separate contributor-facing layer.

That follow-up is tracked in Contributor Quest Mechanics. It describes maintainer-witnessed “outer-world quests” for real capOS development work, such as fixing a full GitHub issue URL or improving QEMU proofs, and limits rewards to badges, temporary states, decorative items, and bounded game-only perks. It must not grant repository authority, OS authority, or any ability to mutate another player’s profile.

Design Grounding

Grounding files for this proposal:

• CLAUDE.md
• README.md
• docs/proposals/index.md
• docs/proposals/interactive-command-surface-proposal.md
• docs/proposals/session-bound-invocation-context-proposal.md
• docs/proposals/shell-proposal.md
• docs/proposals/boot-to-shell-proposal.md
• docs/backlog/runtime-network-shell.md
• docs/proposals/service-object-capabilities-proposal.md
• docs/backlog/stage-6-capability-semantics.md
• docs/security/trust-boundaries.md
• docs/proposals/cryptography-and-key-management-proposal.md
• docs/proposals/volume-encryption-proposal.md
• docs/proposals/storage-and-naming-proposal.md
• docs/proposals/cloud-deployment-proposal.md
• docs/proposals/contributor-quest-mechanics-proposal.md
• docs/proposals/llm-and-agent-proposal.md
• docs/proposals/hosted-agent-swarm-proposal.md
• docs/proposals/capos-repo-harness-engineering-proposal.md
• docs/research/game-mechanics-prior-art.md
• docs/research/plan9-inferno.md
• docs/research/hosted-agent-harnesses.md
• docs/backlog/aurelian-frontier.md
• docs/backlog/hardware-boot-storage.md
• schema/capos.capnp
• system-adventure.cue
• tools/qemu-shell-smoke.sh
• demos/adventure-client/src/main.rs
• demos/adventure-server/src/main.rs
• demos/adventure-npc-wanderer/src/main.rs
• demos/adventure-npc-shopkeeper/src/main.rs
• demos/capos-chat/src/lib.rs