EXP — world-first build plan

Build a person worth returning to, inside the existing EXP pixel world. A short visit should contain one meaningful choice, a visible result, and a comfortable stopping point. Long visits offer depth, not a duty to keep clicking. Safe, bounded plans continue without the player watching.

No mandatory daily claim. No streak-loss anxiety. No notification required to prevent disaster.

Keep the existing renderer, art, camera proportions, movement, interiors, world connections, and story. Do not turn the game into a dashboard, card board, or a new miniature illustration. Mara's standalone lab tested a decision loop; it is not the visual template for EXP.

The first new route is proposed as /demo: a small, isolated region built with the same engine. About 400 × 400 tiles is a starting configuration, not a performance target. Stream its visible regions. Do not instantiate the whole map just because it is smaller than Experia.

Use the latest operator decisions, then the design sources below. Record conflicts rather than silently treating old mechanics as current requirements.

• Life experience: intentions, learning, belongings, and legacy.
• Vision (repository reference): the wider world and accepted boundaries.
• Skill trees (repository reference): 23 disciplines and 69 branches; do not invent a new taxonomy.
• Rollout: system architecture and release gates.
• Simulator: accelerated experiments and uncertainty.
• Migration ledger (repository reference): dated evidence, not a list of confirmed current bugs.

Current code anchors:

This inspection establishes integration points. It does not establish runtime performance or prove all existing routes work. Capture a baseline before changing them.

Use a small Wild Expanse-style region with existing trees, rocks, paths, buildings, and an interior. Use established characters and Lazarus Schlong's story connections. Verify the current introduction before writing dialogue. Mara can appear only where the story supports her role.

Proposed sequence:

1. Wake in the world. Show the character and surroundings, not a wall of controls.
2. Approach a person or useful object. Show one short statement and one clear action.
3. Choose a contribution with a visible local purpose. Repairing a route is a candidate, not new canon.
4. Show immediate work feedback. Finish the project only when its real work and material rules permit it.
5. Show the consequence: a route opens, a person uses it, or a workshop resumes work.
6. Give a useful result and one brief knowledge observation. Source details remain optional.
7. Power up PupBRO. Approve one protected plan with a duration, resource limit, and safe fallback.
8. Close PupBRO and leave. On return, show the changed world and an optional short account of why it changed.

A small task can finish quickly. A road or building cannot appear from one contribution if other work remains. Show the player's actual share; never fake sole credit in a shared world.

The first chapter needs a satisfying end. It may offer another direction, but no countdown or unclaimed prize should make leaving feel like failure. Ordinary choices remain flexible. Reserve irreversible commitments for rare decisions with clear consequences.

The world stays visible by default. PupBRO opens an overlay; it must not resize the game canvas. Preserve camera inset behavior and return keyboard control to the world when the overlay closes.

Use five presentation layers:

• World: terrain, characters, movement, work, and consequences.
• Context: a brief card for the current object or person.
• Quick tools: only assigned, available items; no empty slot furniture.
• PupBRO: plans, people, belongings, journal, and deeper existing systems.
• Essential access: settings, accessibility, exit, and recovery remain reachable without an item.

Start cards with a name, a short fact, and a primary action. Offer alternatives and details only when useful. Never hide material cost, loss risk, or consent requirements to meet a word limit.

Items, events, and experiences may grant HUD functions. Implement a small first-party registry: component ID, grant source, placement, display priority, prerequisites, and dismissal behavior. Separate three states: permission to act, player display preference, and current interaction. Possession does not force a widget onto the screen. A hidden widget does not revoke a permission.

Start with only PupBRO, occupied quick tools, and one contextual instrument. No remote executable plugins. Multiple grant sources must not create duplicate controls. Losing an item must revoke its action safely; keep an unfinished draft where possible and explain what changed. Validate all real actions on the server, not through HUD visibility.

Use stable item IDs. Filtering empty slots must not send an action against the wrong inventory index. Acquiring an item puts it in belongings; it need not pin every new object to the quickbar.

Onboarding reveals one useful control after a relevant action. It can be skipped and resumed. A tour must not wait forever for a hidden widget. Tooltips do not gate walking or world progress. Touch, keyboard, and pointer users receive equivalent choices. Passive updates never steal focus.

Separate game rules from presentation and transport. Use the architecture already proposed in the rollout: versioned transitions, authoritative commands, durable events, and shared rule code for live play and the laboratory. Do not rewrite the renderer to obtain this separation.

Core contracts:

• Life: identity, body, condition, capacity bands, current commitments, and provenance.
• Practice: activity, relevant skill branch, evidence, mentor input, and bounded progress.
• Plan: purpose, place, time budget, required items, reserve, permitted risk, and fallback.
• Project: inputs, remaining work, contributors, output, and a world change.
• Custody: one owner or location per item, with explicit reservations and transfers.
• Knowledge: short observation, source, evidence status, optional depth, and in-world interpretation.
• World event: unique ID, cause, rule version, time, and affected records.

The 23 trees share a data schema. Implement a few representative activities end to end before authoring all branches. Capacity bands describe the current person; skill progression describes learned capability. Do not conflate them or expose all hidden numeric values as a build dashboard.

Plans complete atomically and at most once. Retries, reconnects, two tabs, and worker restarts must not duplicate rewards. Elapsed server time is authoritative. Resource exhaustion or changed conditions selects a safe fallback. A week away may exhaust a finite plan, but it must not create a duty to log in.

Use authored templates plus valid world state for meaningful encounters. Procedural combinations must respect dependencies and history. Generative prose, if later used, cannot mint items, decide legal facts, alter knowledge evidence, or authorize actions.

The target remains 69,420 worlds across 999 clusters over the 23-year Chronicle. Validate the existing catalog totals; do not rebuild them from the shorthand cluster arithmetic. Keep real elapsed time, Ark calendar time, and biological aging explicit and separate.

Active regions simulate detailed interactions. Background regions advance stocks, projects, population cohorts, and scheduled events. Store durable identities and obligations where needed. Expand detail when a region becomes relevant, without inventing facts that contradict recorded history. Lower detail must not erase children, custody, prison terms, ownership, or legacy obligations.

Partition logical worlds across workers. Do not assign one permanent server to every planet. Checkpoint and replay with versioned rules. Benchmark detailed versus coarse outcomes on the same scenarios before using approximation at scale. Storage, compute, and network budgets are release constraints; pixel graphics do not solve them.

The simulator follows the existing S0–S7 plan. Begin with one settlement and conserved materials. Then vary population, roles, automation, ecology, travel, and player behavior. Test 100, 1,000, 10,000, and 100,000 players as scenarios, not promised capacity. Run many seeds and adverse policies; report distributions, collapse rates, bottlenecks, and uncertainty. Do not tune every world to succeed.

The first implementation milestone ends at phase 3, not at a complete galaxy. Phase 4 is necessary before presenting the demo as persistent multiplayer gameplay. Later economy and token work must load their existing review gates; this plan does not approve new monetary rules or a launch.

Experience tests: watch a new player find the first action; count required reading and wrong turns; ask what changed and why. Check satisfaction after a short visit and after an absence. Do not use session length, compulsive return, or notification response as the definition of success.

Rendering tests: use the same viewport and zoom for reference comparisons. Check character scale, feet alignment, occlusion, interiors, world overlays, and canvas dimensions with PupBRO open and closed. Cover small portrait and landscape phones, keyboard navigation, and reduced motion.

Rule tests: fixed-seed replay, conservation, duplicate commands, denied actions, reservations, safe fallbacks, worker recovery, and conflicting project contributions. Headless tests cannot prove that the game is fun. Browser snapshots cannot prove that its economy is stable. Require both.

Release tests: isolate demo state, disable lab time acceleration in live routes, audit route access, test rollback, and retain prior saves. Use feature flags rather than destructive conversion. Keep the existing /play route and migration boundaries intact until an approved promotion.

Work inside EXP. Read AGENTS.md, this plan, its linked sources, and the code touched by the current phase. Report conflicts before changing accepted design. Preserve the existing pixel renderer, assets, proportions, movement, interiors, and story. Never replace them with a separate illustrative demo. Build the smallest complete experience that passes the current phase's exit gate.

For each phase: inspect the baseline, name the scoped change, implement it behind the appropriate boundary, run relevant tests, inspect the actual mounted experience, and report evidence and remaining gaps. Keep rules deterministic where specified and real state server-authoritative. Preserve unrelated work. Do not claim a plan, mock, or editable local save is a shipped system. Do not deploy, launch tokens, incur new spending, or make destructive migrations without the required authority.

Favor meaningful choices, visible consequences, useful knowledge, and safe absence. Reveal depth through context. Keep the world first. When a core design choice is unresolved, propose a reversible default or request the operator's decision. Check weekly usage during substantial work, warn near 20% remaining, and never redeem a reset credit without explicit approval.