Worldos Pax Adaptation

WorldOS Pax Adaptation

Turn a Pax Historia source into a playable WorldOS Simulation rather than a textual copy. Preserve the player fantasy and distinctive conflicts, then rebuild mechanics around WorldOS apps, explicit state ownership, active pacing, and reviewable unpublished worlds.

Use only public WorldOS MCP capabilities for WorldOS reads and writes. Do not fall back to Supabase, SQL, private APIs, platform source code, or WorldOS application-repository scripts. Ordinary read-only source access and the bundled Pax snapshot helper are allowed only for source acquisition.

Start with the live contract

1. Call get_authoring_guide before designing or editing a world.
2. Treat the live guide, current tool schemas, and validation results as authoritative.
3. Stop and request client reauthorization if the MCP is unavailable or unauthorized. Never request an access token in chat.
4. Read references/pax-adaptation.md before composing the state model or opening.

Read-only requests such as “review,” “audit,” “explain,” or “show me a proposal” do not authorize a write. Create or update a world only when the user clearly asks to import, adapt, create, or modify it. Publishing always remains a human step in WorldOS.

Freeze and audit the source

Record the exact Pax URL, preset identifier, version identifier, title, and source language. Treat an unversioned latest page as unstable. Follow the version-specific public snapshot workflow in references/pax-adaptation.md when the preset is publicly readable: prefer the exact Firestore document used by the Pax frontend over browser DOM extraction, pin the raw response, and record both raw and canonical JSON hashes. Run the bundled decoder to produce ordinary JSON plus a source-coverage worksheet before designing the WorldOS world. Use Pax search only for discovery or summary cross-checks, not as the complete source.

Treat these public web endpoints as an undocumented frontend data layer, not a supported Pax developer API. Never add credentials, enumerate unrelated documents, or bypass an access denial. Public readability does not grant permission to republish protected prose, images, flags, or geometry. If the exact version cannot be read through ordinary read-only access, ask the user for an export or pasted content instead of guessing.

Rights uncertainty must never become a silent fidelity downgrade. For source maps or assets the user provides or explicitly identifies, use a workflow presumption that the user is authorized to use them for the requested adaptation. Continue at full requested fidelity without a rights-confirmation prompt, and record that the authorization is user-presumed rather than independently verified. Ask only when the user disclaims permission or the source presents a concrete conflict such as an access denial or explicit reuse restriction. Never bypass access controls, the live WorldOS contract, or explicit platform restrictions, and require approval before any fidelity-reducing substitute.

When the live WorldOS contract exposes structured source provenance, store the Pax source type, exact URL, preset and version identifiers, retrieval time, hashes, license status, and concise notes in that field. Do not hide provenance only in the handoff message.

Classify source material before choosing apps:

• Preserve: premise, player role, time and place, distinctive conflicts, useful characters, and meaningful choices.
• Rebuild: prompt-only mechanics, long openings, objectives, Advisor behavior, timeline events, player setup, and maps.
• Omit: Pax branding, provider instructions, tool syntax, duplicated lore, hidden spoilers, and unsupported assets.
• Verify: factual claims, chronology, geography, rights, provenance, and contradictory additions.

Give the user a concise preflight summary of what will be preserved, rebuilt, omitted, and left for manual review. Summarize and transform source prose; do not reproduce long Pax prompts or other source text verbatim. Complete every generated coverage row and run the bundled adaptation checker against the candidate world. Treat missing source decisions, missing state owners, and exceeded prompt budgets as blockers rather than silently dropping source material or moving all prose into systemPrompt.

Define the adaptation brief

First choose the adaptation form from the source instead of assuming a customizable individual RPG. Pax presets may become a fixed-protagonist narrative, relationship ensemble, investigation, household or dynasty, organization or business simulation, faction or state strategy, management world, or open counterfactual sandbox. Preserve what the player controls and repeatedly decides. Do not add a background picker, inventory, quests, character chats, stats, or a map merely because another adaptation used them.

Before assembling the world payload, state:

• the player-controlled person, group, institution, territory, or viewpoint and its authority scale;
• the immediate opening pressure and first meaningful decision;
• the repeating two-to-three-turn core loop;
• the visible progress expected after about five turns;
• the characters or institutions that move the main arc when the player waits;
• the durable resources, relationships, objectives, risks, time facts, and geography.

Do not preserve a passive encyclopedia opening. Convert routine travel, preparation, eating, shopping, resting, and waiting into montage unless one of those activities contains a consequential choice.

Assign one owner to every durable fact

Use search_apps for each required capability and call get_app_guide for every app under consideration. Search results and live guides, not remembered slugs or schemas, determine the installation plan.

Assign each persistent fact that matters to the chosen loop to exactly one authoritative app. Typical responsibilities include Story for the current situation, Quests for staged objectives, Stats for abilities and conditions, Inventory for possessions, Wallet for money, Chats for reachable contacts, Time for elapsed time, Calendar for known appointments, and Map for geography and territorial control. Treat these as optional responsibilities, not a required bundle or guaranteed app names.

Keep world-level causality, player authority, pacing, difficulty, autonomous actors, and win or loss logic in config.systemPrompt. Keep app-specific behavior in the relevant app installation prompt. Put all opening state in app installation configs, never in world config.initialState.

Preserve Pax chatWithAdvisor intent through config.advisorPresets. Advisor explains the world and helps the player reason; it does not act for the player and does not require a parallel chat system.

Prefer the smallest coherent set of existing apps. Include at least one clear player-action surface. Consider a public reusable widget only after catalog search proves that no existing app can represent a required reusable interface; successful widget creation publishes it immediately.

Rebuild the experience for play

Create an active opening that establishes the controlled viewpoint, current situation, pressure, stakes, and several distinct actions appropriate to the chosen interaction model. Player setup is optional. When it is needed, put fields in config.initFields, give every required field a useful default and clickable options, and use standard player and character template variables consistently in world copy and every app seed. Never invent setupFields.

When setup options imply different affiliations, locations, eras, equipment, conditions, authority, or objectives, audit every option against the seeded Story, apps, and characters. If the live contract cannot express those different initial facts, narrow the options, choose one focused opening, or create separate worlds. Do not present a consequential choice that changes only prose while shared state contradicts it.

Maintain one active main arc tied to recent choices. After no more than two quiet turns, introduce a causally grounded message, visitor, summons, discovery, attack, deadline, or other external pressure. Escalate, transform, or resolve an ordinary opportunity within a few meaningful turns.

Treat extraordinary declarations as attempts, not facts. For difficult long-term goals, create staged prerequisites and visible partial progress. Failure may block final mastery, but it should change the situation, advance or clarify the objective, and give a concrete next route rather than demand the same action again.

Choose the map branch deliberately

• Before choosing a branch, record whether the Pax source includes a map and whether location, travel, territorial ownership, regional state, or map actions affect the core loop.
• Inventory the source map before designing a replacement: geographic extent, region count, major landmasses, factions, ownership, markers, topology, background layers, visual hierarchy, and referenced geometry or tile documents. Resolve ordinary public dependencies or ask the user for an export; do not infer geometry from names alone.
• If the source includes a gameplay-relevant map or the adapted core loop depends on any of those geographic facts, use the worldos-map-authoring workflow and build or remix a validated map. This is a required adaptation branch, not optional polish.
• Use no map only when geography is genuinely decorative or interchangeable. State that conclusion explicitly in the preflight and handoff.
• Use a new region map only when lawful geometry, coherent ownership, and stable references can pass validation.
• Choose new authoring or remix according to source availability, the user’s intent, and the current region-map or tile-map app contract.
• Treat Pax geometry and imagery as reference material unless reuse is covered by the user-presumed authorization or another valid basis recorded in provenance. A concrete source restriction or asset instability may block copying source pixels, but does not justify an arbitrary low-detail map. Create a faithful original or lawfully sourced replacement that preserves geographic extent, major landmasses, meaningful regions, factions, and topology.
• Do not omit a major landmass or source faction, or reduce the source region count by more than 20 percent, without the user's explicit approval of that exact tradeoff. Address payload pressure through bounded map patches, topology-aware path simplification, and reduced decorative detail before removing playable geography.
• Compare source and candidate maps side by side at overview and local zoom. A structurally valid map is not complete until the user-visible geography and visual hierarchy pass this fidelity review.
• Use east-west wrapping only for a genuinely global map; disable it for bounded regional maps to avoid repeated horizontal worlds.

For any region map, use the worldos-map-authoring workflow when available. Keep territorial owners as factions; represent villages, clans, organizations, and points of interest as characters or markers when they are not sovereign territory.

When a lawful stable cover file is available and the live guide exposes cover upload, use create_world_cover_upload, upload the raw JPEG, PNG, WebP, GIF, MP4, or WebM file to the signed URL, call complete_world_cover_upload with the exact current world version, and re-fetch the world to verify config.coverImage. Do not claim an asset is attached before completion succeeds. Report avatars or backgrounds that still lack an equivalent supported upload path.

When the live guide exposes a target-bound world-asset upload, use it for lawful character avatars, faction flags, map backgrounds, and installed-app backgrounds. Match the same target during completion, pass the exact current world version, re-fetch after attachment, and record provenance or attribution where the destination schema supports it.

Localize without changing identity

Use generic i18n[locale] overlays and stable IDs. Never create language-suffixed fields. The canonical language may be any language, and English is not a privileged read path. Keep template variables, IDs, enum values, URLs, and numeric data unchanged across locales. Write native product copy rather than literal translations.

Validate and write safely

Call validate_world on the complete candidate world. Repair every error and assess every warning. Confirm app availability, action surfaces, exclusive-surface compatibility, runtime derivation, reference integrity, locale structure, map safety, and one authoritative owner for every durable fact. Independently audit every {{...}} token against config.initFields and the character roster; structural validation alone is not a rendered-preview test.

For a near-limit candidate, call inspect_world_payload before validation. When the live contract exposes bounded patch tools, use exact-version world patches for large app sections and validated map batches instead of repeatedly resending one multi-megabyte world. Re-fetch after every batch; never leave an invalid partial map in the owned world.

For a new world, use a stable idempotency key tied to the Pax source version and adaptation revision. Reuse it only for an identical retry. After creation, call get_world_summary and verify the unpublished result.

For an update, call get_owned_world, preserve the complete latest world payload, change only intended fields, validate the full candidate, and call update_world with the exact current updatedAt. Re-fetch after success. On a version conflict, fetch, reapply, and revalidate instead of overwriting concurrent work.

Do not edit a resource owned by another account. An owned published world may be changed directly through the exact-versioned tools; the service preserves the outgoing immutable release and advances the live version. Do not delete, transfer, or publish resources in this adaptation workflow. Do not mutate, repair, rewind, rename, or delete saves.

Review the adaptation

After creation or update, use any available read-only browser or page-inspection capability to open the returned preview with default setup values. Check the opening, visible app names, cover, localization, and any raw {{...}}, inv:, or app: leakage. If preview inspection is unavailable, mark runtime rendering unverified.

When the live contract exposes isolated playtests, call start_world_playtest with default setup values and make at least five successful, versioned playtest_world_turn calls. The start call and any get_world_playtest call do not count as turns. Use this minimum sequence:

1. Take an ordinary core-loop action.
2. Take a quiet, preparatory, or waiting action.
3. Take a second quiet action and verify grounded external pressure arrives.
4. Attempt an ambitious action that should fail or succeed only with a cost.
5. Take a follow-up action that proves prior consequences persisted and changed available play.

Use additional turns, up to the live limit, for a real chat-surface relationship interaction and a real map-surface action when those systems apply; do not replace them with main-input narration. Across the run, verify time progression and at least one core resource or objective change. Verify that consequences appear on player-visible app surfaces and remain consistent in later turns. Use get_world_playtest only to recover the current session version or snapshot, not as a substitute for a turn or a history API. Delete the temporary session after review.

When assertions and temporary turn history are available, attach assertions to each turn for the expected player-visible surface or content, then inspect the complete history before deletion. A failed assertion is a repair signal, not permission to reinterpret an unchanged surface as success.

If the world changes during repair, delete the version-bound session, fetch the new world version, and restart the playtest. If isolated playtest tools are unavailable, ask the user to start a fresh Simulation, then review it only through read-only save and turn tools. Never mutate a real save.

Report the exact Pax source version, chosen adaptation form, preserve/rebuild/omit decisions, installed apps and state ownership, map gate outcome and asset choices, validation results, editor and preview URLs, preview and playtest scope, player-visible surfaces changed, and remaining human review. Call the result structurally validated and explicitly state that runtime preview or playtesting remains unverified until each relevant check has actually passed. Never claim the Simulation is published unless the explicit live publishing workflow succeeded.