Migration & Canon Policy

The website has a permanent location for all 20 modules from the existing Module 01 roadmap. Those pages form the wiki’s content spine, not an assertion that the V2 rules are finished.

One growing source of truth

Approved content in this GitHub repository becomes the authoritative Fated Hand V2 source for that specific topic. The approved wiki text is not a copy of a separate master document: it is the maintained source.

1. Reviewed and approved in GitHub: authoritative for that topic, even if a local Word module or older V2 note says something different.
2. Not yet reviewed / not yet migrated: existing modules, V2 rewrite notes and scratchpads remain source material for discussion, not already-approved V2 wiki content. The latest appropriate source can guide play or review in the meantime, but cannot override a newly approved GitHub section.
3. In review or unresolved: explicitly marked as working material or an open design question. Never silently treat a proposal as settled canon.
4. Generated documents and exports: later recreated from the approved GitHub content. They are outputs, not competing authorities.

This authority is section by section, not all-or-nothing at the module level. Approving one section of Combat does not imply that the rest of Module 02 has been reviewed.

Migration statuses

Status	Meaning
Not started	A wiki location exists, but the topic has not been reviewed
In review	Comparing legacy material with V2 direction; not authoritative
Approved	Reviewed and accepted in GitHub; authoritative for this topic
Needs revision	A discrepancy or unresolved interaction has been identified

Working on one section

1. Choose the specific module section or mechanic to work on.
2. Read its existing local source documents and relevant V2 notes; do not bulk-copy them into GitHub.
3. Compare the old rules with the new V2 direction, retaining useful design intent and identifying conflicts or missing decisions.
4. Resolve design questions in the relevant rules/worldbuilding conversation; do not invent answers during website migration.
5. Write the approved V2 rules directly into the appropriate GitHub wiki page, clearly separating approved sections from remaining placeholders.
6. Update cross-links, terminology and any structured game data affected by the change.
7. Treat that approved GitHub section as the new source of truth; any later revision should be made there, with Git history preserving earlier versions.

Only approved player-safe information belongs in public documentation. Fictional identities shared across games belong in the Universe Registry; tabletop-only mechanics belong in the tabletop pages and future tabletop data registry.

Source tracing and conflicts

Record the source module or working document reviewed, and distinguish the origin of an idea from the current canonical version. If an old document and an approved GitHub entry disagree, GitHub wins for the approved topic; flag the old document as superseded rather than copying it back.

If two approved GitHub records conflict, flag the issue for review instead of silently choosing a new rule.

Spoiler and publication policy

A collapsed spoiler is not private. Anything included in a publicly served page can be inspected by visitors. Do not put genuinely secret GM or development information into publicly buildable wiki pages.

Approved opt-in spoilers may later use click-to-reveal controls. True secrets must remain outside public builds or in an access-controlled system. The repository itself is currently private, but that alone does not make any future published site private.

Current V2 transition

The V2 direction revises several older tabletop systems, including the card-use and resource model. This is why the module pages begin as navigation and review placeholders without copying old rules.

The official module roadmap remains owned by Module 01 — Core Engine. Changes to module numbers or ownership require an explicit design decision, rather than incidental website editing.