Wiki

Standards

These rules keep the planning docs consistent and trustworthy.

Status: Active

These rules keep the planning docs consistent and trustworthy.

Status Labels

Use one status per page:

Use these labels in Decision Register:

Locked: approved for review and implementation planning
Open: unresolved and should be treated as a real design question
Later: intentionally deferred and not a blocker for the first implementation pass

Record whether a claim is source-backed, design translation, or assumption.
If a page mentions Minecraft loader, mod version, or server workflow, include the exact version target.
If a page summarizes inspiration-source content, prefer grouped progression data over unstructured item dumps.
If research is incomplete, say so directly.
Put non-negotiables in Project Contract, not only in scattered prose.
Put every meaningful Locked, Open, or Later call in Decision Register.
Treat Phase Registry, Core Ladders, and Pack Baseline as canonical over one-off mentions in other pages.
When implementation changes phase scope, update Phases and Architecture.
When a phase gets its own detail page, update Phase Registry and link it from Phases.

Inspiration pages may use source names.
Core design pages should prefer original project names and terms.
If a direct source mechanic is adopted, document the translation, not just the source reference.
Do not use source names for final boss, relic, mount, weapon, or set naming unless the thing is a vanilla Minecraft material or creature that should stay recognizable.

Each implementation phase should feel playable on its own.

Each phase must define:

Until changed intentionally, the planning baseline is:

If the project moves versions, update these pages first:

Phase names use Phase NN - Name
Pages should prefer singular nouns for systems and plural nouns for grouped catalogs
Content pages should link back to Home
Detailed phase pages should live under docs/wiki/phases/
Player-facing system terms should use the project glossary in Glossary

Custom textures should stay visually native to Minecraft.

Preserve vanilla-style pixel readability and material clarity
Stay close to vanilla detail density instead of drifting into noisy or painterly surfaces
Favor simple shading, readable silhouettes, and restrained contrast
New blocks, items, and mobs should look like they belong beside vanilla assets without calling attention to a different art pipeline
If a design idea only works with a radically different texture style, rework the design instead of breaking the visual language

Do not document direct 1:1 ports as if they were final design.
Every major feature inherited from Necesse or Terraria must be filtered through Minecraft terrain, mob ecology, and survival readability.
Existing Minecraft mobs should be remixed before entirely replacing the world with unrelated enemy rosters.
Mounts, relics, and events should feel native to this project, not like renamed imports with unchanged behavior.

These docs should not: