Phase 15 plan — quests, victory, and the authored example

[mmacy]

Implementation plan for phase 15: the quest spec, the four lifecycle commands with engine-owned quest state and player-visible events, adventure completion into victory, active quests in the player view, the per-level ambient guidance slot, quest/objective validation, and the example rework — the fetch quest authored as adventure data, the interpreter registered, FetchQuestListener deleted.

Notable decisions

• Quests compose the shipped trigger machinery. Activation, objective completion, and reveal are each a TriggerClause (phase 14 pattern + phase 11 conditions); rewards are the existing ConsequenceCommand union under the existing selectors. TriggerSpec is deliberately not restructured around the clause model — its flat shape is serialized inside saved adventures, and the rename would be a schema_version bump bought for symmetry.
• Quest ids are a closed domain — the deliberate inverse of the MarkTriggerFired pin. The view must render names and narrative the log only references, so the lifecycle handlers resolve everything from the spec and reject unknown ids and state-contradicting commands (three new rejection codes). CompleteQuest does not check the completion rule: referee fiat is the surface's standing posture; the interpreter is a disciplined issuer.
• From-start quests are seeded at construction. There is no command channel at session start, so GameSession.__init__ seeds the quest-state block from the adventure — new, load, and replay agree by construction; an activation-less quest emits no activation beat (spec amendment).
• The journal records each quest beat's display text, appended by the handlers themselves (no AddJournalEntry, no JournalEntryAddedEvent for quest beats — the lifecycle event is the beat's event). This resolves the one-journal-field/four-beats collision: the separately authored journal form is the voice of carriers whose display beat the player never sees (a trigger's fired). One narrative carrier is knowingly reassigned (progress moves to the objective's own block) with the docstring rewritten to match.
• Victory is entered in exactly one place — the CompleteQuest handler, mirroring _end_on_party_wipe (clear play state, stick in terminal modes). Rewards land after the transition because they are separately issued logged commands; resume-play rewards drop with notes under the phase 12 carve-outs.
• The example's idol moves into the catalog (bundled GearTemplate, matched by ItemAcquiredPattern; the return objective composes TownEnteredPattern + has_item) and the economy retunes around pay-on-delivery, which restructures the milestone script into two town trips — the town-only sell/heal beats must precede the concluding return, because victory makes them illegal after it.
• Four sentence-level spec amendments ride the implementation PR; docs/adaptations.md gains nothing (no SRD basis). Closing deliverable: the osr-forge issue recording its overrides schema has no quest surface.

Review provenance

Drafted, then rubber-ducked by a fresh skeptical reviewer with the spec, prior plans, AGENTS.md, the crawl code, the examples, and the test surfaces as its reading list. Round one: NEEDS REVISION — two blocking findings (the milestone script's sell/heal are town-mode-only and became illegal after the victory transition, forcing the two-trip restructure; the quest.py deletion census missed docs/front-ends/tui-crawler.md, whose snippet includes would fail the strict docs build) and six non-blocking (the third and fourth spec amendments, the journal-event pin, the referee-fiat boundary, owning the carrier reassignment, and re-justifying the SetFlag reward on its merits instead of assertion continuity). All eight accepted and revised; round two re-verified every fix, stress-tested the two-trip script against the shipped code (cache-take semantics, mode legality, award timing, activation re-matching), and returned SOLID.

https://claude.ai/code/session_01NQ83sqNnXVeXEd55NK1xR7