Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Aurelian Frontier Backlog

Detailed decomposition for growing the current deterministic mission slice into the Aurelian Frontier game described in docs/proposals/aurelian-frontier-proposal.md.

This backlog is not the current selected milestone. It belongs under the Shared-Service Demos track and should be pulled into WORKPLAN.md only when the selected visible outcome changes to a game-depth milestone.

Current Baseline

Implemented:

  • Shell-spawned adventure-client with explicit StdIO, Adventure, and Chat endpoint grants.
  • adventure-server owns per-session-keyed room, inventory, combat, writ, evidence, and effect state using the live endpoint caller-session scoped ref plus epoch. Normal shell launch/grant commands omit legacy badge and receiver-selector syntax, and the focused system-adventure.cue manifest uses omitted-badge service grants for Adventure and its chat-backed NPCs. Explicit selectors remain only outside Aurelian for low-level compatibility and hostile-path fixtures.
  • Typed adventure methods exist for look, movement, inventory, inspect, use, status, combat, authority verbs, delegation, order, seal, and leave.
  • Aurelian expedition mission proves ward-writ, Maro route evidence, ward-wraith combat, Livia delegation, spell/skill/guard effects, eagle-standard recovery, witness-certified temple custody, survivor evacuation, gate sealing, downed-state refusal, and leave cleanup.
  • adventure-content contains the pure targeted-combat foundation from commit f149119: deterministic combat zones, damage kinds, attack and mob profiles, bounded zone damage, fatigue cost, pressure interruption, recognition level, and alert propagation helpers.
  • Inventory and status output now split player state into Items, Writs, Relics, Marks, and Evidence.
  • chat-server labels replayed room history and separate NPC processes prove chat-only actors with process-exit observation.

Known limitations:

  • Item inspection text and most state-transition/failure text still live in Rust handlers.
  • Relic recovery uses a dedicated typed recover cap method; take and drop are reserved for physical inventory items.
  • NPCs that matter to world state are mostly server text, not separate actors holding scoped game authority.
  • Aurelian chat-only boot NPCs share init’s system session under session-bound chat membership. The QEMU smoke proof therefore treats them as one session-keyed chat member: all greetings must be visible, Centurion Varro is the single deterministic polling reply actor, and independent concurrent NPC replies are future work. Distinct concurrent NPC chat memberships need distinct spawned session contexts, not raw init-spawned boot services.
  • Generated combat profiles now reach adventure-server for the current mobs and are proven through the QEMU scenario process, but explicit weapon/zone command parsing, durable alert groups, pending interruption state, stealth openings, and authority-combat verbs remain open.
  • Rank, faction, debrief, market, party, and item-transfer logic are still bounded proof slices, not durable profile/ledger subsystems. PvP consent and two-client multiplayer proofs are not present.

Implementation Posture

The kernel capability model remains the authority boundary. Game code should not be trusted because it is written in Rust or Lua; it should be trusted only to the extent that it holds narrow caps and correctly uses typed capOS interfaces. A useful game demo should eventually show both Rust and Lua code using the capability model properly.

Rust remains the right implementation language for bounded state, no-std userspace services, typed Cap’n Proto calls, deterministic QEMU proofs, and resource validation.

Do not let Rust become the long-term content authoring language. Larger room graphs, mission beats, item descriptions, dialogue hints, aliases, shop catalogs, and debrief text should move into a bounded data-driven mission format before the Aurelian content grows materially.

Keep this split:

  • The kernel owns authority enforcement through capabilities, while Rust services own simulation rules, combat resolution, object limits, schema encoding, and failure behavior.
  • Mission content owns room/site data, visible descriptions, actor dialogue, aliases, lead text, deterministic encounter placement, and debrief records.
  • Lua can later own deterministic scenario glue and NPC behavior when the capos-lua runner exists: mission beats, state-machine dialogue, debrief variants, quest-board text, and scripted reactions that still call typed capOS/game interfaces through granted caps.
  • Runtime loading may stay compile-time embedded at first, but the content must pass the same validator used by host tests and QEMU smoke setup.

Candidate content formats:

  • CUE: consistent with existing manifest tooling and validation style, but needs a bounded conversion path for no-std userspace.
  • RON: compact Rust-native authoring, but adds another format and tooling convention.
  • TOML: familiar for simple data, weaker for graph validation and nested mission rules.

Prefer CUE if the implementation can reuse existing host-side validation and generate a bounded Rust data blob. Avoid runtime parsing in the game service until there is a concrete reason.

Near-Phase Gates

The first game-depth milestone must produce a player-visible improvement. A branch that only moves the existing hardcoded room data into a generated blob is technical prep, not completion of the near phase. The first complete near-phase slice must keep the current Aurelian expedition mechanically stable while also making the path discoverable through canonical ids, aliases, lead text, and specific failure messages.

Legacy endpoint badges are not part of the Aurelian authority model. New Aurelian phases must keep player, party, NPC, and chat participation keyed by session-bound invocation context or by future broker-granted service facets, not by manifest-assigned or user-selected receiver selectors. The focused run-adventure gate rejects system-adventure.cue if badge: fields are reintroduced.

Input and content bounds for the near phase:

  • command lines accepted through the current StdIO adapter: 256 bytes;
  • typed object ids, actor ids, mob ids, writ ids, directions, spell names, and skill names: 64 bytes, ASCII alphanumeric plus _ and -;
  • chat say text and future free-form command text: 256 bytes after trimming, with no semantic parsing beyond the declared text field;
  • generated content ids and aliases: same 64-byte id rule unless a reviewed schema/runtime change raises it;
  • room/site titles: 80 bytes; descriptions: 320 bytes; lead and failure hint lines: 160 bytes; actor dialogue and debrief lines: 320 bytes;
  • content lists must use the explicit per-player, per-site, and per-room caps in this file, not unbounded vectors.

If generated mission content is checked in, every branch that changes content or the generator must provide a freshness check equivalent to make generated-code-check; stale generated Rust blobs are a review finding.

Authority-RPG Direction

The next design target is a compact expedition RPG where rare authority is RPG power fantasy, not paperwork. The core loop is:

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

Design rules for subsequent backlog slices:

  • Writs are loot: gear, skill tree, access key, social status, and sometimes curse. A good writ changes what the player can do, carries inspectable issuer/scope/expiry/delegation/revocation rules, and may have bounded affixes or drawbacks under the mission seed.
  • Classes are authority archetypes: Warden, Marshal, Archivist, Custodian, Factor, and Heretic/Renegade. Differences come from legal, social, and supernatural verbs, not generic damage numbers.
  • Delegation is buildcraft. Companion loyalty, ambition, competence, reputation, fear, and doctrine should affect how delegated authority behaves under pressure.
  • Combat attacks authority as well as HP. Forgers, null-priests, bandit captains, corrupt magistrates, spies, oathbreakers, and wraiths should threaten writs, custody, witnesses, route grants, and legal control.
  • Denial should reward with leads: a missing witness, hidden jurisdiction, forged seal, rival claim, corrupt actor, unsafe state, rank gate, or alternate route.
  • Progression unlocks reach: new jurisdictions, deputy appointment, remote revocation, relic custody capacity, hostile negotiation, disputed shrine access, and operating without a local witness in constrained cases.
  • Base modules unlock verbs. Archive, Temple vault, Barracks, Court, Market hall, Signal tower, and Sanctuary should affect future expeditions through explicit actions, not passive percentage bonuses.
  • Controlled randomness covers mission complications, route hazards, faction demands, companion behavior, relic side effects, enemy authority tricks, optional objectives, and loot/writ modifiers. The legal model remains deterministic and auditable under a seed.
  • Multiplayer stays scoped to cooperative expedition pressure first. Defer MMO scale, open economies, broad construction seasons, LLM-critical NPCs, federation, and worldlines until the compact expedition loop is excellent.

Near-term sequence after the pure combat targeting foundation in f149119:

  1. Generate combat profiles from CUE for the current mobs and reject malformed zones, damage kinds, alert groups, recognition thresholds, and stealth references through make generated-code-check.
  2. Integrate those profiles into adventure-server so inspected attacks use deterministic zone damage, fatigue, interruption, recognition, and alert helpers. Keep clients from submitting computed damage.
  3. Extend text parsing only as needed for unambiguous proof commands: attack <mob> [zone] [with <weapon>], cast <spell> at <mob> [zone], and one authority-combat verb such as inspect seal or expose forgery.
  4. Add the first authority-attacking enemy behavior without broad new systems: a forged route/custody claim or seal conflict that can be inspected, exposed, and resolved during the existing expedition.
  5. Add a small writ-affix proof using authored or fixed-seed content: one writ modifier with a meaningful drawback, printed in inspect/status output and enforced by the service.
  6. Add one delegation-buildcraft proof for an existing companion: a trait such as loyalty, competence, or doctrine changes the outcome of delegated ward-writ or custody authority and explains the causality.
  7. Add one base/rank reach unlock at debrief, such as Archive evidence verification, Temple vault custody upgrade, or Signal tower remote revocation, without starting a general construction/base-management system.
  8. Prove the sequence through 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. Keep the shell transcript to representative parser coverage.

2026-04-29 09:41 UTC status: generated combat profiles for current mobs landed in adventure-content CUE, generator output, and pure content validation. Adventure server/client/scenario integration remains open.

2026-04-29 10:23 UTC status: adventure-server now fails closed at startup if any hard-coded runtime mob lacks a generated combat profile. Runtime mob ward state comes from generated profile metadata, and server-owned attack, skill, and cast handlers use pure target-zone mitigation plus profile fatigue cost for the current deterministic proof actions. Ordinary look/status mob lines stay rough; exact zone armor, ward value, pressure, focus, alert radius, and counter details are revealed only after mob inspection or combined scout/wizard support, while intent remains visible with scout or wizard support. Recognition and alert helper results are surfaced as readable combat facts, but durable alert groups, pending interruption state, explicit weapon/zone targeting, and authority-combat verbs remain open.

Phase 1: Player-Visible Mission Substrate

Visible outcome: a first-time player can complete the current Aurelian expedition without reading source or memorizing hidden ids, and the read-only mission content comes from a validated generated blob instead of hardcoded room tables and scattered text. The mission path and existing QEMU transcript outcomes stay stable, but look, status, inspection, and failures become clearer.

  • Define a bounded AdventureContent model for sites, exits, visible items, actors, mobs, aliases, objectives, leads, and scripted proof-path metadata.
  • Add host validation for content graph integrity: unique ids, valid exits, valid aliases, referenced actor/item/mob ids, bounded text length, and deterministic ordering.
  • Generate or embed a compact static Rust representation for userspace; keep runtime parsing out of the no_std service unless explicitly justified.
  • Add a generated-content freshness check and wire it into the relevant branch verification so checked-in content blobs cannot drift from source mission data.
  • Move current square, tavern, garden, cellar, map, coin, key, scout-marker, and ward-wraith descriptors into content data.
  • Keep all state-changing behavior in Rust handlers; content may select text and ids but must not bypass authority checks.
  • Extend AdventureRoomView or status text so look presents objective, visible interactables, actors, active mobs, exits, and one lead line.
  • Add canonical-id display for objects, actors, mobs, writs, and exits.
  • Add alias resolution for common casing and titles, with responses that name the resolved canonical id.
  • Add near-miss suggestions for known ids, starting with common failures such as ward -> ward-writ, wraith -> ward-wraith, and livia casing.
  • Improve invalid order results so they name plausible next actions when player knowledge allows it.
  • Split status text into survival state, mission state, held/delegated authority, evidence/effects, and lead.
  • Add host tests for rejecting malformed content graphs.
  • Keep make run-adventure transcript stable after the migration and add assertions for at least one canonical-id suggestion and one improved actor-task hint.

Implementation notes:

  • Start with read-only content fields. Do not introduce a general scripting engine for mission logic in this phase.
  • Keep object ids ASCII, stable, and bounded by the near-phase limits above unless a reviewed schema/runtime change raises those limits.
  • Lua scripting belongs after the data model exists. Do not use Lua to bypass the content validator or make transcript-critical behavior depend on an unbounded script.

Phase 1b: Deterministic Scenario Scripting

Visible outcome: once capos-lua can run scripts with exact grants, selected scenario and NPC behaviors can move from Rust match branches into deterministic Lua scripts without changing the authority boundary.

  • Use docs/proposals/lua-scripting-proposal.md as the scripting design source.
  • Expose only narrow game host APIs to scripts, such as read current mission state, choose a dialogue branch, emit a debrief line, or request a typed game action through a granted object cap.
  • Keep mission authority, inventory mutation, relic custody, combat damage, and cap transfer in kernel-enforced capability calls and Rust service handlers.
  • Add deterministic script fixture tests for NPC state machines and scenario beats.
  • Add QEMU transcript coverage showing one Lua-scripted NPC or scenario reaction using a granted cap and one denied ungranted path.
  • Keep Rust and Lua examples side by side so the demo proves capability discipline is language-independent.

Cut scope:

  • No dynamic native Lua modules, no broad ProcessSpawner, no raw CapIds in scripts, and no script-owned authority beyond the runner’s CapSet.

Phase 1c: Non-Deterministic NPC Brains

Visible outcome: non-transcript-critical NPC flavor can later use the language-model/agent proposals without weakening deterministic proofs.

  • Use docs/proposals/llm-and-agent-proposal.md for any LLM-backed NPC implementation.
  • Keep LLM NPCs behind narrow caps and treat model outputs as suggestions or dialogue data, not authority.
  • Restrict LLM use to ambient tavern chatter, optional hints, flavor summaries, or player-facing explanation when exact transcript output is not part of the proof.
  • Keep main mission success paths, combat outcomes, custody decisions, policy denials, and QEMU smoke assertions deterministic.

Deferred from Phase 1:

  • Dynamic completions belong with the future CommandSession interface and should not duplicate full parser logic in the StdIO adapter.

Phase 2: Aurelian Expedition Map

Visible outcome: the playable mission uses the proposed frontier expedition locations rather than the four-room prototype.

  • Replace prototype content with a small Site graph: fort_aurelian, gate_yard, ashen_road, signal_tower, and under_vault.
  • Model site metadata: region, threat level, exits, visible items, actors, active wards, and optional required route authority.
  • Implement the first mission objective: recover eagle-standard from the ruined signal tower.
  • Add complications: unstable tower gate, wounded legionary behind a ward, guild scout route information, and temple witness custody requirements.
  • Provide at least two acceptable good outcomes, such as recovered standard plus sealed gate, or recovered standard plus survivor evacuation.
  • Update make run-adventure to drive the new mission path with stable assertions.

Cut scope:

  • Do not add random mission variants in this phase.
  • Do not split mission state into a new service until the single-server model blocks explicit authority or proof coverage.

Phase 3: Authority Inventory And Relic Custody

Visible outcome: player-facing inventory makes authority, evidence, and relic custody visible without implying every entry is a pick-up item.

  • Split inventory/status output into Items, Writs, Relics, Marks, and Evidence.
  • Keep take and drop for physical items only.
  • Keep request, accept, delegate, and revoke for authorities.
  • Add relic custody state for eagle-standard, including a failure path when the player lacks temple or rank authority.
  • Add temple-seal or equivalent witness-certified custody proof.
  • Ensure relic failures distinguish missing location, missing authority, unsafe state, and witness refusal.
  • Add QEMU assertions for relic custody denial, successful custody, and audit/evidence status output. Complex custody coverage now runs in the capOS adventure-scenario-test userspace process through real Adventure cap calls; the shell-driven adventure-client transcript remains representative interactive client coverage.

Phase 4: Persistent Profile And Ledger Substrate

Visible outcome: player profile data and mission evidence have bounded save/load semantics, while ordinary client launches remain fresh unless the player explicitly resumes an expedition.

  • Define bounded Cap’n Proto records for AdventureProfile, AdventureExpeditionCheckpoint, and AdventureLedgerRecord, including schema version, content hash or release id, profile id, record/checkpoint version, size limits, and migration policy.
  • Add host tests for save-record encode/decode, first schema-version acceptance, unknown-content rejection, over-limit rejection, stale-version rejection, and wrong-profile rejection.
  • Add the AdventureProfileService summary substrate for bounded create/load/save, local non-reward settings and progression updates, and validation of rank marks, warrior stars, wizard circles, faction standing, cosmetics, contributor badges, title choices, and settings.
  • Connect AdventureProfileService reward and title mutations to ledger-backed authorization once AdventureLedger exists, so rank marks, faction standing, cosmetics, contributor badges, and title choices are applied from auditable mission facts rather than direct summary edits.
  • Add AdventureLedger as append-only mission evidence: debrief records, relic custody, forbidden-rite use, witness certifications, reward mints, market/trade receipts, and revocations.
  • Add AdventureExpeditionService for active expedition checkpoints: current site, objective state, player state, party state, mob state, pending events, and turn ordering.
  • Add AdventureSaveStore as the only persistence adapter used by the profile, ledger, and expedition services. It may target RAM, local disk-backed Store/Namespace, or a future CloudGameStore, but gameplay services should not call provider-specific APIs directly.
  • Prove the local baseline first: save and reload a profile, append and replay one ledger record, and explicitly checkpoint/resume one expedition through RAM-backed or disk-backed store semantics.
  • Keep run adventure-client fresh by default. Add an explicit resume command or profile option before loading active expedition state.
  • Add proof coverage for one rejected stale checkpoint write and one rejected wrong-profile load.

Cut scope:

  • Do not make the kernel persist process memory or the live capability graph.
  • Do not merge divergent combat checkpoints automatically; reject stale writes and require the player or service to pick a checkpoint.
  • Do not require GCP to pass the local QEMU proof path.

Phase 5: Cloud Persistence Bridge

Visible outcome: the same profile, ledger, and expedition records can be stored through an optional cloud-backed capability without changing game service logic.

  • Define CloudGameStore as a narrow bridge with save/load/append operations matching the local AdventureSaveStore semantics.
  • Keep the GCP bridge outside the game authority boundary: the bridge stores records, but AdventureProfileService, AdventureLedger, and AdventureExpeditionService decide which mutations are valid.
  • Use Firestore Native mode only for mutable profile/index documents and transactional compare-and-set style updates.
  • Use Cloud Storage for versioned snapshots and larger evidence blobs, with object versioning and lifecycle policy so old snapshots do not accumulate without bounds.
  • Use Cloud Run or an equivalent narrow service endpoint for the bridge and Secret Manager for bridge-side service credentials. Do not expose those credentials inside ordinary game clients.
  • Add local fake-cloud tests that enforce the same stale-write, wrong-profile, append-only-ledger, and size-bound behavior before using real GCP services.
  • Add an operational note for project, region, IAM service account, retention, backup/export, and cost controls before any real deployment.

Operational note:

  • The first real deployment must use a dedicated Google Cloud project per game-world environment, or an equivalently isolated folder/project split for development, staging, and production. Record the project id, numeric project number, billing account owner, support contact, and break-glass owner in the deployment runbook before enabling writes.
  • Choose one primary region for the Cloud Run bridge, Firestore database, Cloud Storage buckets, Secret Manager secrets, and Cloud KMS keys unless a reviewed multi-region design exists. The runbook must name the region and the data-residency reason; cross-region replication is a separate design decision because it affects latency, cost, and recovery semantics.
  • Cloud Run is the only provider-facing bridge endpoint in this phase. Ordinary capOS game clients see only the CloudGameStore capability and never receive Firestore document names, bucket names, OAuth tokens, service account keys, Secret Manager secret names, or broad network/provider authority.
  • The bridge must not be public. Launch requires authenticated invocation, no allUsers or disabled-invoker-IAM setting, an explicit Cloud Run ingress mode, and a named invoker identity for the capOS bridge path. Public HTTPS exposure or unauthenticated browser calls would bypass the CloudGameStore capability boundary even if provider credentials remain hidden.
  • The bridge runs as a dedicated service account. Isolate Firestore by database or project boundary, then enforce adventure collection/document path allowlists in bridge code before issuing provider calls; do not rely on Firestore security rules or collection-scoped IAM for server-side access. Grant only the database-level Firestore role needed by the isolated database, Cloud Storage object access for the configured adventure buckets, Secret Manager secret access for named bridge secrets, and KMS encrypt/decrypt authority for the configured game-world key. Do not grant project owner/editor, wildcard bucket admin, or user-browser OAuth authority to the bridge.
  • Firestore Native mode holds mutable profile/index documents and version/CAS records only. Every mutable write must read the current document version and commit inside a transaction or equivalent preconditioned update; stale writes fail closed and preserve the current document.
  • Cloud Storage holds immutable or versioned records: expedition snapshots, larger evidence blobs, exports, and content-addressed objects. Buckets must enable object versioning before production writes and must have a lifecycle policy bounding noncurrent versions and abandoned exports. Versioning is recovery, not immutability: create-only evidence and content-addressed writes must use generation-match preconditions, and audit evidence that must resist replacement or deletion needs an explicit retention policy or hold gate before launch.
  • Retention policy belongs in the runbook before launch: profile/index documents keep only the current mutable summary plus required audit references; ledger/evidence objects retain enough noncurrent versions for recovery and audit; debug exports and test objects have a short TTL. Legal hold, public world audit, or contributor-reward evidence retention needs separate approval before becoming indefinite.
  • Backup/export is explicit. Schedule Firestore exports and Cloud Storage inventory or backup jobs to a separate restricted bucket, record restore drills, and verify restore through CloudGameStore validation rather than accepting provider bytes as authoritative.
  • Cost controls are launch gates: configure budgets and alerts for Cloud Run requests/egress, Firestore reads/writes/storage, Cloud Storage live and noncurrent object bytes, KMS operations, and Secret Manager access. Add lifecycle rules before enabling object versioning so stale snapshots do not grow without bounds.
  • Provider credentials stay bridge-side. Prefer service account identity and Secret Manager references over static keys. If a static credential is unavoidable for a development bridge, record its rotation owner, expiry, allowed environment, and revocation procedure; never put it in manifests, game save records, browser JavaScript, or QEMU transcripts.

Cut scope:

  • No direct Firestore/Cloud Storage calls from adventure-client or adventure-server.

Sequencing note:

  • Cross-device multiplayer through GCP is on the roadmap, but it must wait until local multiplayer authority, session-bound invocation context, and stale-write rejection are already correct behind AdventureSaveStore and CloudGameStore. The cut is sequencing, not a permanent scope exclusion.

Phase 6: User-Owned Browser Save Vault

Visible outcome: private player data can be exported and imported as signed, encrypted save capsules through a browser using user-granted Google Drive or Firebase authority, without making those blobs authoritative for shared world state.

  • Define UserSaveCapsule with schema version, capsule version, profile id, device id, content hash, migration policy, record kind/version, previous capsule hash, plaintext hash, ciphertext, AEAD algorithm, signature algorithm, signer public key id, signature, and timestamp.
  • Define the save-vault key-boundary policy model for local capOS-host key material, GCP game-world Cloud KMS authority, and browser transport authority.
  • Use storage-domain encryption keys: local capOS-host key material for local storage and GCP Cloud KMS envelope encryption for GCP-backed data, with a per-world or per-shard KMS KEK wrapping service-owned DEKs. The browser transports ciphertext and provider handles; it must not receive DEKs, SymmetricKey caps, KeySource caps, KMS decrypt/unwrap grants, or provider-independent plaintext authority.
  • Prefer Google Drive appDataFolder with the narrow drive.appdata scope for personal backup files that the user should not edit directly.
  • Allow Firebase/Firestore user documents only as a transport/cache for encrypted capsules. Firestore/Firebase rules can bind access to the authenticated user through an explicit {request.auth.uid} path template, but cannot validate encrypted game semantics.
  • Add KMS/IAM design notes for the GCP path: one key ring/key per game-world instance or shard, narrow decrypt authority for the game-world service, key rotation policy, and revocation behavior for retired worlds.
  • Add restore validation in AdventureSaveStore: signature, content hash, schema version, profile id, previous hash, monotonic version, size bounds, and wrong-profile rejection.
  • Add rollback policy: importing an older private checkpoint may restore an explicit local expedition snapshot, but it must not erase append-only ledger facts, contributor rewards, market receipts, or public multiplayer outcomes.
  • Add host tests for tampered ciphertext, wrong signing key, wrong profile, stale version, unknown content hash, oversized capsule, and replayed old capsule.
  • Add a web-terminal or browser-companion fixture path with fake Drive and fake Firebase adapters before using real Google APIs.

Cut scope:

  • No authoritative public world state from user-owned blobs.
  • No direct provider SDKs inside adventure-server.
  • No mandatory Google account for local QEMU adventure proof.
  • No silent cloud sync; export/import or sync must be visible user action or profile setting.
  • No browser-held game-world key capabilities, KMS decrypt/unwrap grants, or provider-independent plaintext authority.

Phase 7: Actors As Capability-Bounded Processes

Visible outcome: important NPCs have process identity and only the capabilities their role needs.

  • Keep adventure-server as the authority owner until direct NPC mutation needs are explicit.
  • Add actor content and chat behavior for Centurion Varro, Magister Livia, Acolyte Iunia, Maro the Guild Scout, Wounded Legionary, and Gate Echo.
  • Give chat-only NPC processes only console and the narrowest available chat authority. The focused manifest now uses omitted-badge chat grants; user-selectable or manifest-assigned receiver selectors must not be part of this proof.
  • For any NPC that can affect world state, add a separate scoped broker-granted AdventureNpc facet or equivalent session-bound service authority. Do not use receiver-selector compatibility grants as NPC mutation authority.
  • Route NPC offers and refusals through player-visible commands and chat events rather than hidden server side effects.
  • Add focused smoke assertions proving each resident chat-only NPC process launches and contributes visible room chat history under session-bound chat membership.
  • Add distinct service sessions, chat participant ids, or a scoped AdventureNpc facet before requiring every boot-launched NPC process to act as an independently polling chat participant.

2026-04-26 chat-only actor slice, updated 2026-04-29: system-adventure.cue launches the six named Phase 7 actor processes with only console plus omitted-badge chat grants. After the session-bound invocation-context migration, those boot-launched actors inherit init’s system session, so chat membership intentionally collapses to the service-scoped caller-session key instead of legacy per-process receiver selectors. make run-adventure now proves every named actor published visible room history, the designated Centurion Varro actor produced the single deterministic polling reply, and the other same-session chat actors exited after greeting. Independent per-NPC chat participants remain blocked on distinct service sessions, chat participant ids, or a future broker-granted AdventureNpc facet. Direct world-mutation NPC authority remains unimplemented and intentionally unchecked above.

Phase 8: Tactical Combat And Mob State

Visible outcome: combat remains deterministic and bounded, but offers more than repeating attack.

  • Add a bounded mob model with hp, armor, ward, attack, morale, traits, intent, and threat level.
  • Keep ward-wraith; add at least two of imp-scout, ash-ghoul, gate-hound, and echo-centurion.
  • Implement command-level turns: player action, eligible ally action, hostile action, deterministic transcript.
  • Add visible intent when scout or wizard support makes it available.
  • Add retreat and at least one blocked-retreat failure.
  • Extend guard to protect an ally when one is present.
  • Add QEMU assertions for one intent line, one ally-related combat action, and one deterministic hostile response.

2026-04-26 Phase 8 first tactical slice: the adventure-server now uses a bounded deterministic mob model for ward-wraith, gate-hound, and imp-scout; gate_yard and ashen_road expose the added mobs through generated content. Command-level combat turns produce deterministic player, ally, and hostile transcript lines, guard livia protects the next hostile response, and retreat has a blocked gate-hound failure plus a successful pressure retreat. The adventure-scenario-test capOS process is the primary QEMU proof for intent visibility, ally guard/hostile response behavior, deterministic hostile response, successful retreat, and blocked retreat.

Cut scope:

  • No random combat outcomes until seeded mission variants land.
  • No hidden dice rolls that make QEMU transcript assertions fragile.

Follow-up combat architecture, grounded by docs/research/game-mechanics-prior-art.md:

  • Use Evil Islands as planning input for tactical fight shape, especially targeted body zones, damage-type/armor matchups, stealth openings, visibility-dependent enemy recognition, fatigue/retreat pressure, cast interruption, and equipment-derived combat effects. This is not a clone target; Aurelian keeps command-level turns, capability-gated authority, deterministic smoke coverage, and service-owned outcomes.
  • Move mob combat definitions out of hard-coded adventure-server templates and into validated generated content once the first targeted combat slice needs more than hp/armor/ward/attack/morale/traits/intent. Content should name damage affinities, zone armor, alert groups, recognition thresholds, stealth-opening permissions, and cast-interrupt vulnerability.
  • Extend adventure-content pure logic before server integration: CombatZone, DamageKind, CombatAttackProfile, MobCombatProfile, deterministic target-zone damage, fatigue cost, interrupt outcome, recognition level, and alert propagation helpers. Unit tests should cover each rule without QEMU.
  • Extend CUE content and tools/adventure-content-gen beyond the current generated mob combat profiles when alert groups, stealth openings, or richer profile references land. The current generated-code freshness path covers profile presence, zones, damage kinds, armor/ward/focus bounds, recognition thresholds, and alert radius for current mobs.
  • Add typed Adventure surface only where the existing text target cannot stay unambiguous. A likely first step is parsing attack <mob> [zone] [with <weapon>] and cast <spell> at <mob> [zone] in adventure-client, while keeping schema changes explicit if structured target/zone/weapon fields become necessary for the browser client.
  • Update AdventureRoomView or status output only after a structured view is needed. Unknown mobs should initially expose rough threat/posture; inspected or combined scout/wizard-supported mobs can expose zone armor, ward state, alert risk, and likely counters. Intent is visible with scout or wizard support.
  • Keep adventure-server as the authoritative combat state owner for the first slice. Server state now tracks per-mob hp/ward/morale, revealed knowledge, and profile fatigue for current proof actions, and clients do not submit computed damage. Limb/zone effects, durable alert state, and pending interruption remain future work.
  • Add targeted attacks with a small fixed zone set: head, hands, legs, and core. Zone effects should be deterministic: head increases disruption/critical payoff at higher risk, hands weaken attacks or casting, legs weaken pursuit or charge intent, and core remains the reliable default.
  • Add damage-type and mitigation metadata for weapons, spells, armor, ward state, and zone armor. Keep result text explicit, for example naming why a spear, mace, blade, ember spell, or ward spell mattered.
  • Make enemy recognition depend on scout support, wizard support, distance, height/route position, and prior codex evidence. Unknown mobs may reveal only posture and threat; inspected mobs reveal zone armor, ward state, intent, and likely counters.
  • Add stealth-opening support for ambush/backstab-style advantages without requiring real-time precision: if the player approaches unseen and has a valid weapon/route, the first command can gain bounded damage or interruption.
  • Add pull/alert behavior where noisy movement, failed stealth, or an escaping scout can wake related mobs. The service must print the causality and keep the smoke path deterministic.
  • Tie combat output to equipment construction inputs from Phase 11c: weapon/shield/focus/cloak object type, material, facility quality, warrior stars, wizard circles, and remaining enchantment budget affect bounded damage, guard, fatigue, interruption, and resistances.
  • Add explicit fatigue and cast-interruption rules for sustained magic, heavy equipment, running, and retreat. Fatigue should create meaningful retreat/guard choices rather than a hidden accuracy penalty, and monsters must not get unfair infinite-fatigue behavior.
  • Add QEMU scenario coverage through adventure-scenario-test for one inspected targeted attack, one damage-type/armor explanation, one stealth or scout-enabled opening, one alert/pull response, one cast interruption or fatigue-gated refusal, and one deterministic retreat/blocked-retreat interaction. Keep shell transcript assertions to representative parser behavior and stable smoke output.
  • Keep rewards mission-audited. Do not add enemy grinding as a rank, warrior-star, wizard-circle, or faction-standing source.

2026-04-29 09:09 UTC, commit f149119 first pure targeted-combat foundation: adventure-content now exposes no-std deterministic combat targeting primitives for zones, damage kinds, attack and mob profiles, bounded zone damage, fatigue cost, pressure interruption, recognition level, and alert propagation. Pure Rust tests cover the rules without QEMU. Generated combat profiles, Adventure command parsing/server integration, and scenario proof remain open.

2026-04-29 10:23 UTC targeted-combat integration update: generated combat profiles are loaded by adventure-server for all runtime mobs and missing profiles fail closed at startup. The scenario proof covers inspected profile-backed output and applied profile fatigue through actual Adventure cap calls. Command parsing for explicit zone/weapon targeting, durable alert/pull state, pending interruption, and authority-combat verbs remain open.

Phase 9: Skills, Spells, Ranks, And Reputation

Visible outcome: player competence affects available actions and future grants without becoming a grind.

  • Model player rank labels: tiro, signifer, centurion, and legate.
  • Keep warrior stars and wizard circles visible in status, but make them policy inputs for brokered authorities.
  • Add missing skills from the proposal as needed by the first mission: shield-wall, counter, rally, or narrowed equivalents.
  • Add missing spells as needed by the first mission: mend-wound and stabilize-gate before higher-circle spells.
  • Add explicit failure text when rank, stars, or circles block an action.
  • Add debrief outcomes that update rank marks, faction standing, and evidence records from auditable mission facts.
  • Add QEMU assertions for one rank/circle denial and one debrief reward.

2026-04-28 17:46 UTC, commit d09243d Phase 9 first competency slice: adventure-content now carries host-testable PlayerRank, PlayerCompetence, skill/spell gate, and debrief promotion policy. The adventure server exposes rank, rank marks, Aurelian standing, prepared skills, and prepared spells in status; shield-wall, counter, mend-wound, and stabilize-gate use the shared gates while rally remains explicitly reserved for later centurion command authority. The QEMU adventure-scenario-test asserts a pre-debrief shield-wall rank denial, validates mend-wound target denial, proves partial temple custody does not suppress a later debrief reward, then proves the promotion to signifer, warrior-star update, standing mark, and debrief-aurelian-route evidence from audited mission facts.

Deferred:

  • dome-shield, demon-brand, and high-circle gate rewriting are later campaign scope unless a focused proof needs them.

Phase 10: Market And Logistics

Visible outcome: the shopkeeper becomes a small capability-shaped economy proof instead of flavor chat.

  • Add typed verbs for quote, buy, sell, trade, and repair before accepting them as implemented gameplay.
  • Define bounded market roles: quartermaster, guild scout, temple annex, and field engineer.
  • Implement one deterministic route purchase or favor exchange with Maro.
  • Implement one authority-gated refusal, such as focus equipment requiring wizard circle 1 or temple certification requiring clean custody.
  • Define trade/custody transfer as a service-mediated transaction protocol, not two save-file edits: reserve or escrow both sides, commit or release with idempotency keys, reject stale versions, record one ordered ledger receipt, and specify cancellation, retry, and crash-recovery behavior.
  • Ensure prices and blocked authority are named in failure text.
  • Add QEMU assertions for one quote, one successful exchange, and one rejected trade explaining the gate.

2026-04-28 18:12 UTC, commit 47dbfc5 Phase 10 first market/logistics slice: Adventure now exposes typed quote, buy, sell, trade, and repair methods through the schema, client wrapper, shell client parser, and adventure server. The deterministic QEMU scenario covers Maro’s route purchase, a quote naming price/gate/receipt, and Iunia’s clean-custody trade refusal naming the temple-seal gate. The full service-mediated transaction protocol remains open.

2026-04-28 planning update, grounded by docs/research/game-mechanics-prior-art.md: after the first Phase 10 market slice, use external game-mechanics research as planning input only. Stardew Valley is useful for calendar pressure, seasonal resource tables, festivals, routine changes, quests, gifts, affection, and crops that expire at season boundaries except when explicitly multi-season. EVE Online is useful for regional markets, market-eligible item classes, brokered buy/sell orders, immediate matching, and blueprint/material/facility manufacturing constraints. Evil Islands is useful for equipment construction where item properties come from material, gold, level, skill, object type, and a limited enchantment budget. Its combat model is also useful for targeted body zones, damage-type and armor matchups, scouting/visibility, stealth openings, pull/alert risk, fatigue, and cast interruption. The capOS-specific translation is not to clone those games; it is to turn the stable mechanics into capability-shaped tasks below: seasonal cycles, regional settlements and outposts, service-owned order books, blueprint/artifact construction, targeted deterministic combat, token-budgeted agent NPCs, and a rich tilemap client.

Phase 11: Seeded Variation

Visible outcome: repeated runs vary content meaningfully across normal play, while the smoke transcript stays reproducible under a fixed seed.

First slice status: live adventure player state is keyed by endpoint caller-session scoped refs instead of legacy receiver badges, and generated mission content now carries fixed smoke seed/variant metadata that is printed in status output and asserted by the adventure scenario cap-call path. This is only the deterministic seed metadata foundation. The Phase 11a calendar foundation adds a fixed smoke calendar state and bounded seasonal resource availability primitives in generated content; seeded gameplay variation, production per-run seeds, festivals, NPC routines, and full seasonal economy behavior remain open.

  • Add generated mission content fields for a fixed smoke seed label and selected variant metadata.
  • Add manifest or mission setup field for a fixed mission seed and a separate per-run seed for production play.
  • Print seed and selected variant metadata in transcript/debug mode.
  • Seed mob placement, optional hazards, shop inventory, rumor lines, loot cache locations, debrief complications, and ambient encounter timing.
  • Seed seasonal state for normal play: season, day, weather/hazard class, seasonal resources, festival/event hooks, and NPC routine variants. The deterministic smoke seed now forces a stable generated calendar state, but normal-play seed selection remains open.
  • Keep season-sensitive resource tables bounded: crops, forage, fish, shop stock, route hazards, and outpost production all have explicit per-site caps and stable sorted output under a fixed seed.
  • Keep combat outcomes reproducible under a fixed seed; production play may add bounded variance per turn as long as the smoke seed reproduces the recorded transcript.
  • Add scenario assertion for seed and variant metadata through real Adventure cap calls.

Phase 11a: Calendar, Seasons, And Resource Cycles

Visible outcome: the frontier feels alive across repeated sessions without making proof transcripts nondeterministic.

  • Add an AdventureCalendar model with four 28-day seasons as the initial default, explicit day advancement rules, and debug output for the fixed smoke seed.
  • Attach bounded fixed-smoke seasonal availability primitives to generated content for crops, forage, fish, shop inventory, route hazards, and repair/material production. Multi-season resources must be declared explicitly.
  • Apply seasonal availability to gameplay systems. Quartermaster field-rations quotes now read the fixed-smoke seasonal shop-stock table, and Adventure.status now forecasts carried seasonal crops expiring plus fish/forage degrading at the next season change. Actual inventory aging and removal/replacement of expired or degraded carried goods remain open.
  • Add festival and military-event records that can temporarily change actor locations, shops, witness availability, debrief choices, and rumor lines.
  • Give named actors bounded routine variants by season, festival, mission beat, and local emergency. Routine changes must be visible as structured actor presence/state, not hidden text-only flavor.
  • Add simple quest/gift/affection hooks only after profile and ledger facts can record them. Daily interactions and gifts should affect actor standing through auditable records, not client-owned counters.
  • Add pure Rust unit tests for calendar rollover, season/day bounds, seasonal resource eligibility, multi-season exceptions, and stable fixed-seed ordering.
  • Add pure Rust unit tests for festival scheduling once festival records exist.

Phase 11b: Regional Settlements, Outposts, And Trade Routes

Visible outcome: Aurelian is one settlement in a wider frontier economy with multiple cities, outposts, production sites, and routes.

  • Model more than one settlement: fort_aurelian remains the proof settlement, while later content can add at least one civilian city, one temple-administered site, one guild waystation, and multiple resource outposts.
  • Define outpost roles such as mine, farm, timber camp, shrine, gate-yard, salvage yard, and repair yard. Each role produces bounded resources, consumes supplies, exposes route risks, and may require specific writs.
  • Add region and route metadata: distance, hazard, faction control, route authority, cargo limits, seasonal closure, and known-safe/unknown states.
  • Extend markets from actor-local deterministic handlers toward a service-owned regional market with market-eligible item classes, brokered buy orders, sell orders, price/time priority, immediate matching when price crosses, expiry, fees, and ordered ledger receipts.
  • Route player, NPC, and outpost transfers through the open Phase 10 service-mediated transaction protocol: reserve or escrow both sides, commit or release with idempotency keys, reject stale versions, and record one ordered receipt.
  • Add scenario tests using a real Rust test client process that calls game caps for multi-step market flows: quote, reserve, partial failure, cancellation, retry, crash-recovery state, and receipt replay. The quartermaster seasonal shop-stock quote now has real Adventure.quote coverage; reserve/commit/failure flows remain open.

2026-04-28 20:08 UTC, commit 48c62db Phase 11b foundation: generated content now includes bounded regional settlement, outpost, and route records. The foundation covers fort_aurelian, a civilian city, a temple-administered site, a guild waystation, five resource outpost roles, and eight route metadata records with distance, hazard, faction control, route authority, cargo limits, seasonal closures, and known-safe state. Adventure status prints a concise regional frontier summary, and adventure-scenario-test asserts it through a real Adventure.status cap call. Service-owned regional market order books, escrow/transactions, NPC or outpost transfer flows, and full economy behavior remain open.

Phase 11c: Blueprint And Artifact Construction

Visible outcome: equipment and artifacts become authored constructions with traceable materials, skills, facilities, and enchantment limits.

  • Add blueprint records for craftable equipment, repair jobs, gate parts, relic containers, focus items, and lawful wards. Blueprints name required materials, facility class, skill/rank/circle gates, expected duration, cost, and output bounds.
  • Keep construction service-mediated. A crafting job reserves materials and currency at a location, validates blueprint/facility/rank constraints, records the job, and either completes or releases the reservation.
  • Add deterministic property-derivation primitives as a bounded result of base blueprint, material, facility quality, and paid cost. Full crafting job integration remains open.
  • Add artifact construction metadata for rare pieces whose authority matters: witness-sealed relic cases, warded cloaks, focus rings, route compasses, golem cores, and gate-stabilizer parts.
  • Add enchantment slot metadata and validation bounds. The constrained post-process gameplay remains open until construction jobs exist.
  • Add pure Rust unit tests for blueprint validation, material/property derivation, enchantment slot limits, facility/rank/circle gates, and missing or retired authority references.
  • Add service-side material reservation and stale construction job rejection once a pure job-state model or construction service exists.

2026-04-28 21:08 UTC, commit 0b7db05 Phase 11c foundation: generated content now contains bounded construction material, facility, blueprint, artifact, and enchantment-slot metadata. adventure-content validates blueprint id uniqueness, material references and quantities, facility class/location references, rank/star/circle gates, cost/duration/output quality bounds, artifact authority gates, and enchantment slot limits; it also derives deterministic construction properties from blueprint/material/facility/cost inputs. Adventure status prints a concise construction summary, and adventure-scenario-test asserts that line through a real Adventure.status cap call. Service-mediated construction jobs, material reservation, escrow/transactions, completion/release, and full artifact crafting gameplay remain open.

Phase 11d: Token-Budgeted Agent NPCs

Visible outcome: optional agent-controlled NPCs can feel reactive while staying bounded, auditable, and outside transcript-critical authority.

  • Use docs/proposals/llm-and-agent-proposal.md, docs/proposals/hosted-agent-swarm-proposal.md, docs/proposals/capos-repo-harness-engineering-proposal.md, and docs/research/hosted-agent-harnesses.md as grounding before any implementation.
  • Treat model output as dialogue or proposed action data. Mission-critical authority, custody, combat, market commits, rank rewards, and policy denials stay in deterministic services.
  • Add an NpcAgentBudget or equivalent service-owned quota: per actor, session, day, and model profile; input/output token limits; tool-call limits; cooldown; and exhaustion behavior.
  • Let NPCs spend quota on bounded chatter, optional hints, and outpost status summaries. Spending must be visible in logs/debug output for review.
  • Extend token-budgeted NPCs to personal routines, shop negotiation flavor, and festival reactions once those deterministic service states exist.
  • On quota exhaustion, fatigue, sleep schedule, or policy denial, the NPC should refuse in-world, for example: I'm tired. Going to sleep. The refusal must not be a hidden transport error.
  • Keep hosted-agent memory separate from authority. Long-lived NPC memory can record bounded facts and reflections, but only reviewed/compiled facts influence deterministic game services.
  • Add tests with a deterministic fake model that proves quota decrement, quota exhaustion refusal, no authority mutation from free text, and stable transcript output when agent NPCs are disabled.

2026-04-28 21:36 UTC, commit f53d044 Phase 11d foundation: generated content now carries disabled-by-default optional NPC agent budget metadata for Iunia, Livia, and Maro, including per-session and per-day input/output token limits, model profile, tool-call limits, cooldown, fatigue, sleep schedule, refusal line, and audit visibility. adventure-content owns a deterministic fake-model turn function for bounded chatter, hints, and outpost summaries; it decrements quota, refuses in-world for quota, fatigue, sleep, cooldown, and policy-denial blocks, and exposes spending as debug/audit-visible data. Pure Rust unit tests prove quota decrement, quota exhaustion refusal, sleep/fatigue/cooldown/policy refusal, disabled-agent transcript stability, bounded output counts, budget validation, and that free text/proposed action data cannot mutate authority snapshots. Adventure status prints only an aggregate fake-agent budget line, and adventure-scenario-test asserts that line through a real Adventure.status cap call. Live LLM calls, hosted-agent service execution, durable memory service, autonomous NPC actions, authority mutation from model output, transcript-critical LLM gameplay, and service-owned construction or market state remain open.

Phase 12: Multiplayer, Parties, And Lawful PvP

Visible outcome: shared multiplayer authority works correctly across local multi-client play first, with cross-device play following on the same service-mediated boundaries. Players can party up, delegate scoped authority, assist each other, and engage in lawful PvP without leaking private inventory or allowing ambient harm.

  • Do not start this phase until Adventure and chat authority use session-bound caller identity, or future broker-granted service facets, rather than receiver-selector identity. The first bounded slices key local player labels from live caller-session metadata.
  • Add Expedition or equivalent shared state only when the single Adventure service cannot cleanly model party authority. First bounded slice keeps deterministic party state inside Adventure because no cross-service coordinator is needed for local create/invite/ accept/leave/delegate/assist records.
  • Add party verbs: create, invite, accept, leave, and delegate. Implemented for service-created local labels derived from live caller-session keys. The labels are local Adventure handles such as player-1, not caller-selected badges or global principal/session data.
  • Add assist <player> with <task> for deterministic cooperative action. Implemented for the first detect-ward assist record. The assist requires party membership plus delegated ward-writ; it records scoped service-owned state and does not grant unrelated inventory authority. Commit 335a9ee at 2026-04-28 22:22 UTC routes these transitions through the unit-tested adventure-content party state and asserts the one-client cap surface through adventure-scenario-test.
  • Route first player-to-player physical-item transfer through a single-owner atomic mutation path inside Adventure. Implemented as transfer <item> to <player> / Adventure.transfer for service-local player labels derived from live caller-session keys. The first slice requires both players to be in the same party, refuses eagle-standard relic custody, mutates source and target inventories atomically inside the existing service, and covers success/failure invariants in pure Rust transfer tests. One-client cap assertions cover unknown target, self transfer, missing item, and unchanged status or inventory on refusal without faking a second live session.
  • Add currency escrow and broader two-party trade/custody transfer protocol only after the economy model and multi-client proof harness justify it; user-owned backup capsules must not be transfer authority.
  • Add a two-client QEMU proof with two service-created player objects, one shared party, one delegated writ, and one assist. The proof must use two distinct live caller-session keys for Adventure cap calls, not manifest receiver selectors or user-chosen identity. Still open: the current focused Adventure manifest does not yet provide a reliable two-client launcher/session harness with two distinct live caller-session keys for Adventure cap calls. This slice therefore keeps the real cap-client assertion to one-client party surface coverage and covers complex transitions in pure Rust tests.
  • Keep PvP opt-in: duel, spar, contest, or bounty authority must exist before harmful verbs can target another player.
  • Add denial text for unauthorized player harm that names the missing lawful conflict authority. attack <player-label> now refuses known local player labels with text naming the missing duel/contested-yard authority. Duel/spar/contest/bounty authority remains future work.

Sequencing note:

  • The first slice is local multi-client (two clients on one capOS instance) because that is the cheapest deterministic proof. Cross-device multiplayer is on-roadmap and lands once the local authority model is correct and CloudGameStore carries shared expedition/ledger state.
  • Network-transparent multiplayer (full federation across capOS instances) stays separate from this phase and follows the broader networking work.

Future Phase: Parallel Universes And Worldline Federation

Visible outcome: separate capOS-hosted Aurelian worlds can expose alternate seeded worldlines and limited cross-world interaction without making remote instances trusted authorities for local inventory, relic custody, profile standing, or market settlement.

This is deliberately after local multiplayer, durable ledger/profile state, service-owned market/escrow, and basic networking. The near-term shape is not a single shared MMO world. It is a federation of sovereign worldlines, each with its own content release, worldline id, seed epoch, generated overlays, ledger head, market policy, and profile-import rules.

  • Add a WorldlineSeed model whose outputs are deterministic artifacts: generated regional overlays, seasonal economy tables, event schedules, market starts, outpost production, route hazards, optional encounters, loot caches, and bounded NPC routine variants.
  • Keep authored anchors static: factions, core law, major sites, named relics, capability interfaces, canonical proof missions, and security policy. Seeded generation may vary conditions around those anchors, but must not mint new authority classes or bypass service-owned validation.
  • Store provenance for every admitted generated artifact: content release id, worldline id, seed epoch, generator version, scope label, provenance hash, and bounded output size.
  • Add pure deterministic generator tests before gameplay integration: same seed produces the same artifacts, different seeds produce bounded variation, invalid generated references are rejected, and generated outputs remain sorted/stable for proof transcripts.
  • Add fixed-seed QEMU proof once the generator exists. The smoke path should still use pinned selections until generator coverage is strong enough.
  • Define WorldlineDirectory, WorldlineVisit, WorldlineExpedition, WorldlineTransfer, and WorldlineAudit service surfaces as local facade caps over remote protocol messages. Do not serialize raw cap slots, endpoint generations, global session ids, or local player labels as portable authority.
  • Start with echo-only federation: list a remote or second local worldline, inspect content/seed/ledger metadata, and view public state without mutation authority.
  • Add a denial proof for cross-world relic transfer before implementing successful transfer: eagle-standard transfer must fail until custody escrow, remote policy, dual-ledger receipts, content compatibility, and replay protection exist.
  • Later, add envoy visits and expedition bridges. Projected remote characters may observe, chat, or perform explicitly granted low-risk actions; spending home-world inventory or importing rewards requires a transfer/settlement receipt.
  • Treat cross-world markets and migration as receipt-verified claims. Remote order views, faction standing, rank, contributor rewards, and custody history require local policy gates before they affect local authority.

Feasibility note: this is feasible if it is built as capability federation plus deterministic worldline generation. It is not feasible as “trust another capOS instance’s save file” or “transfer local caps over the network.” Cross-world state changes need the same reserve/escrow, commit/release, stale-version rejection, idempotency, and ledger receipt discipline already planned for local markets and trades.

Phase 13: Contributor Quest Mechanics

Visible outcome: after the base Aurelian game has stable profiles, evidence, debriefs, and cosmetic rewards, the game can recognize real capOS development work through maintainer-witnessed outer-world quests.

  • Use docs/proposals/contributor-quest-mechanics-proposal.md as the design source for this phase.
  • Keep all rewards cosmetic, narrative, reputational, or bounded game-only perks unless a separate reviewed security design grants authority.
  • Use full GitHub issue and PR URLs, commit hashes, issuer identity, and timestamps in contribution evidence records.
  • Add manual quest and witness records before any read-only forge connector.
  • Add QEMU proof that witnessed contribution evidence mints a badge or decoration, while an unwitnessed claim does not.

Cut scope:

  • No automatic GitHub mutation, no token handling in the game client, no public leaderboard that pressures maintainers or security reviewers, and no reward that grants repository or OS authority.

Phase 14: Rich Browser Adventure Client

Visible outcome: after WebShellGateway, session-bound game authority, profiles, persistence, and the core game loop are stable, a browser-hosted adventure client presents the same game as a pixel-art interface with animated characters, location art, inventory panels, combat affordances, and chat/event feeds. The browser client should feel like a native game client, not a terminal skin.

  • Treat adventure-client as the text/QEMU proof client and compatibility adapter. Do not route the rich browser UI through StdIO command lines.
  • Implement the web shell or WebShellGateway side as a capability-call proxy for the authenticated session. The gateway holds the real capOS caps and invokes only the allowed adventure/chat methods for that web session.
  • Keep the browser authority opaque: browser JavaScript receives web-session handles and typed DTOs, never raw capOS CapIds, badge selectors, provider credentials, shell spawn authority, game-world keys, or broad network capability.
  • Prefer narrow game-session objects such as AdventurePlayer and ChatParticipant with methods for look, movement, inventory, status, combat actions, orders, delegation, chat send/history, and bounded event polling. A generic CommandSession may coexist for terminal-style front ends, but it is not the required ABI for a purpose-built game UI.
  • Return structured view state and events suitable for rendering: current site, exits, actors, mobs, visible items, held/delegated authority, evidence, effects, party state, combat state, animation/event cues, and chat history cursors.
  • Represent the world as a 2D tilemap data model for browser presentation: maps, tilesets, tile layers, object layers, collision/interaction zones, spawn points, actor paths, region/outpost markers, and event triggers. Tiled JSON is an acceptable authoring/export candidate if validation rejects oversized maps, missing tiles, unknown layer types, and invalid object references.
  • Evaluate PixiJS plus @pixi/tilemap for the first rich client because it gives a WebGL-oriented 2D renderer and rectangular tilemap path with a canvas fallback. This is a client rendering choice, not game authority.
  • Keep all semantic validation in game services. Browser-side disabled buttons, command palettes, targeting hints, and animations are presentation only; the server still rejects missing authority, invalid location, stale state, bad custody, unsafe combat, and oversized input.
  • Use explicit asset manifests for pixel art, sprite sheets, portraits, tiles, VFX, UI sounds, and animation ids. Asset lookup must not grant game authority, and missing or mismatched assets must fail as presentation errors rather than game-state mutations.
  • Add a headless browser harness that authenticates through the web gateway, opens the rich client, drives one deterministic mission slice using UI actions, verifies rendered state transitions/events, and checks logout or tab-close teardown.
  • Add browser rendering checks for tilemap layer order, actor placement, viewport/camera bounds, collision affordance display, event feed updates, and no browser-side mutation of authoritative adventure state.

Blocked by:

  • WebShellGateway authentication, origin/TLS policy, session teardown, and bounded browser transport.
  • Broker-granted Adventure/chat authority or gateway-owned live caller-session mapping so web sessions do not depend on caller-selected receiver identity.
  • Persistent profile/ledger/checkpoint semantics for save/resume UX.
  • Stable core gameplay phases through at least authority inventory, relic custody, actor roles, combat, and debrief rewards.

Cut scope:

  • Do not make browser-rendered state authoritative.
  • Do not let browser UI bypass game service methods or mutate save records directly.
  • Do not require the rich browser client for QEMU proof coverage; the text client remains the deterministic low-dependency proof path.

Service Split Gates

Keep one adventure-server until there is a concrete proof value in splitting state. Split services only at these gates:

  • Mission service: when multiple clients or NPCs need shared expedition state independent of private player profiles.
  • Profile service: when rank marks, cosmetics, contributor badges, or settings must persist beyond one process lifetime.
  • Audit/Witness service: when relic custody, forbidden rites, and debrief evidence need a separate authority boundary.
  • Save store: when profile, ledger, or expedition state needs a shared adapter over RAM, local disk, or cloud backing.
  • Cloud bridge: only after local save/load semantics and stale-write rejection are proved behind AdventureSaveStore.
  • User-owned save vault: when private profile/export data should sync through a user’s browser or Google account without granting provider credentials to game services.
  • Market/Trade service: when two-party exchange or shop inventory becomes more than a deterministic local handler.
  • Expedition service: when parties, assists, duels, or contested sites need shared state and explicit consent capabilities.

Every new service split must include manifest grants and QEMU assertions for both allowed behavior and at least one rejected overbroad action.

Verification Gates

For each phase that changes behavior:

  • make fmt-check
  • make generated-code-check when schema or generated bindings change.
  • Generated content freshness check when mission source data or content generation changes.
  • Relevant host tests for content validation or pure logic.
  • Prefer pure Rust unit tests for complex deterministic game logic: calendar/season rules, resource tables, blueprint validation, market matching, escrow state machines, route constraints, and agent quota accounting.
  • Use a real Rust test client process calling game caps for complex scenario tests that cross service boundaries: custody, construction, market transactions, party assists, and regional economy flows.
  • Keep the current command-client transcript focused on basic command and client functionality: parsing, rendering, representative success/failure calls, and stable QEMU smoke proof. Do not make it the only coverage for complex game state machines.
  • Save-record encode/decode and migration tests when profile, expedition, ledger, or cloud-bridge persistence changes.
  • User-save capsule tamper/replay/wrong-profile tests when browser-mediated backup or restore changes.
  • make run-adventure with deterministic transcript assertions for the new behavior.

For content-only changes:

  • Content validator tests must pass.
  • Generated content freshness check must pass when content blobs are checked in.
  • make run-adventure must still prove the visible mission path.

Do not claim the full adventure proposal is implemented until the Aurelian mission, authority inventory, actor roles, relic custody, debrief, and deterministic proof path all land.