Plan: Aurelian Frontier Followups
Overview
Iterate the Aurelian Frontier proof slice – a generated-content adventure
demo whose authoritative scenario process owns regional markets, calendar
events, construction jobs, party transitions, agent NPC budgets, and
authority-combat verbs. Long-form decomposition lives in
docs/backlog/aurelian-frontier.md; the proof slice description is in
docs/demos/adventure.md and the deterministic mission slice is captured
in commit history (see WORKPLAN.md observable milestones for hash-pinned
landings).
Goal of each iteration: pull one or two open follow-ups from
docs/backlog/aurelian-frontier.md into reviewable shape, exercise them
through the real scenario process under make run-adventure, and keep
generated content in demos/adventure-content/content/prototype.cue
plus demos/adventure-content/ deterministic.
Conflict Surface
Owned by this plan:
demos/adventure-content/(includingdemos/adventure-content/content/prototype.cue),demos/adventure-server/,demos/adventure-client/,demos/adventure-scenario-test/,demos/adventure-chat-actors/,demos/adventure-npc-shopkeeper/,demos/adventure-npc-wanderer/,demos/remote-session-adventure-worker/(only Adventure-side changes; the remote-session worker boundary is shared with the remote-session plan – coordinate before changing the bridge), and any newdemos/adventure-*crate- Aurelian-specific Adventure interface extensions in
schema/capos.capnp(shared serial surface – seedocs/plans/README.mdConcurrency Notes; only one plan at a time may changeschema/capos.capnp, andmake generated-code-checkmust pass before the next plan picks it up) system-adventure.cueand the matchingmake run-adventuretargetdocs/demos/adventure.md,docs/backlog/aurelian-frontier.md,docs/proposals/aurelian-frontier-proposal.md
Do not touch from this plan:
tools/remote-session-client/(owned by remote-session plan)demos/paperclips-*(owned by Paperclips plan)- Kernel-core cap tables, scheduler, or device manager
- Repo-root
system-*.cuedefaults migration scope (owned by system-config slice 3 plan), exceptsystem-adventure.cuedirect edits
Validation Commands
make fmt-checkmake generated-code-checkcargo build --features qemucargo test-configcargo test-libcargo build-demos-caposmake run-adventuremake run-remote-session-adventure-interop(required when the iteration changesdemos/remote-session-adventure-worker/or the Adventure call shape consumed by the remote-session worker)
Success Criteria
Each landed iteration must keep make run-adventure green, leave the
content tree deterministic, and update docs/backlog/aurelian-frontier.md
to mark the corresponding follow-up done with a commit hash. Game-depth
expansion past the deterministic mission slice stays opt-in until the user
explicitly redirects priority.
Task 1: Pick the next backlog follow-up to land
- Read the open backlog items in
docs/backlog/aurelian-frontier.mdand pick the smallest one that still produces a visible scenario assertion (no architectural restructure unless the user asks). - Sketch the proof shape: which
Adventure.*calls change, which generated content fields move, and what the QEMU assertion checks. Capture the sketch as a commit-message-shaped paragraph in the task branch’s worktree handoff. - Confirm the slice does not require new kernel-side caps or a new
schema interface; if it does, stop and route the prerequisite
through
WORKPLAN.md.
Task 2: Implement the picked follow-up in adventure-content first
- Add or update generated content in
demos/adventure-content/content/prototype.cueand the matching pure Rust validation indemos/adventure-content/. - Cover the change with
demos/adventure-scenario-test/(and anydemos/adventure-content/host tests) for bounded transitions, replay safety, and any new admission helper. - Keep all source-game identifiers, text, and exact balance values out of generated content; reuse the clean-room shape proven in earlier Aurelian phases.
Task 3: Wire adventure-server and the scenario process
- Implement the matching server-side state mutation, idempotent
replay, and stale-version rejection in
adventure-server. Keep service-owned vs player-local state separated as in earlier phases. - Update the real scenario process (the QEMU proof binary) so it
drives the new
Adventure.*calls and asserts the visible state inAdventure.status,Adventure.inventory, or the related view. - Confirm
make run-adventurepasses, then snapshot the run-adventure log into the dedicated worktree.
Task 4: Doc and changelog updates
- Mark the follow-up done in
docs/backlog/aurelian-frontier.mdwith commit hash and minute-precision timestamp. - If the follow-up changes the proof shape visible to operators,
update
docs/demos/adventure.md. - Add a
docs/changelog.mdentry referencing the commit.
Task 5: Optional second slice in the same iteration
- Only if the picked follow-up was small and the run-adventure log stayed bounded, pick a second open backlog item and repeat Tasks 1-4 for it. Otherwise leave this checkbox unchecked and stop.
- Keep both slices in one task branch only when their changed file sets are disjoint and the proof binaries do not interleave state.