@@ -139,7 +139,9 @@ Start with V4 Milestone 1 (research foundation) and Milestone 2 (Genichiro runti
 
 V3 is released. Sections 7–17 remain the reference for how the current product is built; their product rules (lightweight attempt recording, honest analytics, per-user isolation, one language per page) still apply.
 
-Public deployment is V4 Milestone 9.
+Public deployment is V4 Milestone 7.
+
+V4 covers vanilla Sekiro only. All Resurrection mod work is deferred until after `v4.0.0` (section 35).
 
 Practice recommendations are part of V5.
 
@@ -701,15 +703,16 @@ No single source should automatically override all others.
 
 # 20. Rulesets
 
-V4 must introduce the concept of a combat ruleset.
+Every dataset carries its combat ruleset.
 
-At minimum:
+V4 covers only:
 
 ```text
 Vanilla Sekiro
-Resurrection Mod
 ```
 
+The Resurrection mod is a separate ruleset. Its work is deferred until after `v4.0.0` (section 35), but the ruleset label stays on every dataset so it can be added later without reworking vanilla data.
+
 Version metadata should be preserved where possible.
 
 Do not combine Vanilla and Resurrection observations into one unlabeled dataset.
@@ -751,7 +754,7 @@ Example responsibilities:
 
 ```text
 rulesets/
-→ Vanilla / Resurrection version metadata
+→ ruleset version metadata (vanilla in V4)
 
 characters/
 → product boss ↔ character ID mappings
@@ -806,7 +809,7 @@ Raw extracted game assets should remain local and gitignored.
 
 Create:
 
-- ruleset metadata
+- vanilla ruleset metadata (Resurrection metadata is deferred with the rest of the Resurrection work)
 - research folder structure
 - ground-truth schema drafts
 - local asset paths through configuration
@@ -821,7 +824,7 @@ Do not modify the production DB merely to anticipate later needs.
 
 Use Genichiro as the first vertical slice.
 
-Start with Vanilla unless explicitly choosing Resurrection first for a specific experiment.
+Vanilla only.
 
 Objectives:
 
@@ -874,7 +877,7 @@ Runtime instrumentation should shrink the static reverse-engineering search spac
 
 # 26. V4 Milestone 3 — Static Engine Mapping
 
-After obtaining runtime identifiers, trace them into engine/mod data.
+After obtaining runtime identifiers, trace them into engine data.
 
 Possible chain:
 
@@ -893,7 +896,6 @@ AtkParam / Bullet / SpEffect
 Use:
 
 - Debug Menu / developer runtime information
-- Resurrection override files
 - targeted original-game extraction
 - DSAnimStudio or equivalent animation inspection
 - TAE extraction
@@ -905,7 +907,9 @@ Do not introduce tooling simply because it exists.
 
 ---
 
-# 27. Resurrection Analysis Strategy
+# 27. Resurrection Analysis Strategy (Deferred)
+
+Deferred until after `v4.0.0`, together with section 35. Kept here for when that work starts.
 
 Treat Resurrection as:
 
@@ -1083,27 +1087,7 @@ Do not claim absolute mathematical completeness unless evidence supports it.
 
 ---
 
-# 32. V4 Milestone 6 — Resurrection Ground Truth
-
-After the Vanilla pipeline is understood, build the Resurrection mapping.
-
-Classify differences as:
-
-```text
-unchanged
-modified
-new_in_resurrection
-vanilla_only
-same_semantic_move_different_engine_sequence
-```
-
-Every gameplay/video observation must carry its ruleset.
-
-This becomes essential for future CV training.
-
----
-
-# 33. V4 Milestone 7 — Product Integration
+# 32. V4 Milestone 6 — Product Integration
 
 Only after the research schema stabilizes:
 
@@ -1129,8 +1113,42 @@ Let the actual research data determine the relational model.
 
 ---
 
+# 33. V4 Milestone 7 — Public Deployment
+
+Public deployment is intentionally deferred until V4.
+
+Before deployment ensure:
+
+- authentication works reliably
+- user isolation is tested
+- bilingual UI works
+- database migrations are reproducible
+- verified content is distinguishable from uncertain content
+- at least one ground-truth vertical slice is integrated
+- `attempts.user_id` is made NOT NULL through a migration. V3 left it nullable so attempts recorded before accounts existed could stay ownerless until claimed with `python -m scripts.claim_attempts <username>`. The migration should fail loudly if any ownerless attempts remain.
+
+Production concerns may include:
+
+- HTTPS
+- production PostgreSQL
+- secure environment variables
+- database backups
+- migration execution
+- secure cookies
+- deployment workflow
+- logging
+- recovery
+
+Choose infrastructure based on actual hosting requirements.
+
+Do not introduce Kubernetes by default.
+
+---
+
 # 34. V4 Milestone 8 — Boss Expansion
 
+Starts after `v4.0.0` (section 36).
+
 After Genichiro is complete enough to validate the pipeline, expand boss-by-boss.
 
 Do not immediately process every boss in parallel.
@@ -1155,35 +1173,25 @@ The ground-truth pipeline should become more automated with each boss.
 
 ---
 
-# 35. V4 Milestone 9 — Public Deployment
+# 35. Deferred — Resurrection Ground Truth
 
-Public deployment is intentionally deferred until V4.
+Not part of V4's vanilla milestones. It starts after `v4.0.0`; whether in a v4.x release or after V5 is the project owner's decision.
 
-Before deployment ensure:
+Once the vanilla pipeline is understood, build the Resurrection mapping.
 
-- authentication works reliably
-- user isolation is tested
-- bilingual UI works
-- database migrations are reproducible
-- verified content is distinguishable from uncertain content
-- at least one ground-truth vertical slice is integrated
-- `attempts.user_id` is made NOT NULL through a migration. V3 left it nullable so attempts recorded before accounts existed could stay ownerless until claimed with `python -m scripts.claim_attempts <username>`. The migration should fail loudly if any ownerless attempts remain.
-
-Production concerns may include:
+Classify differences as:
 
-- HTTPS
-- production PostgreSQL
-- secure environment variables
-- database backups
-- migration execution
-- secure cookies
-- deployment workflow
-- logging
-- recovery
+```text
+unchanged
+modified
+new_in_resurrection
+vanilla_only
+same_semantic_move_different_engine_sequence
+```
 
-Choose infrastructure based on actual hosting requirements.
+Every gameplay/video observation must carry its ruleset.
 
-Do not introduce Kubernetes by default.
+This becomes essential for future CV training.
 
 ---
 
@@ -1211,6 +1219,8 @@ v4.2.x
 
 This avoids turning “all bosses complete” into an unbounded release blocker.
 
+Resurrection is not part of `v4.0.0` (section 35).
+
 ---
 
 # 37. V5 — Automated Gameplay Analysis
@@ -1591,9 +1601,16 @@ V3 is released. Work through V4 in milestone order:
 5. Completeness review (V4 Milestone 5)
 ```
 
-The later V4 milestones (Resurrection, product integration, boss expansion, public deployment) follow once Genichiro's pipeline is proven.
+Then, to complete `v4.0.0`:
+
+```text
+6. Product integration (V4 Milestone 6)
+7. Public deployment (V4 Milestone 7)
+```
+
+Boss expansion (V4 Milestone 8) follows in v4.1.x. Resurrection is deferred until after `v4.0.0` (section 35).
 
-Keep the released V3 product working: fix product bugs on `dev` as they appear, and do not change the production schema for ground-truth research until V4 Milestone 7.
+Keep the released V3 product working: fix product bugs on `dev` as they appear, and do not change the production schema for ground-truth research until V4 Milestone 6.
 
 ---
 
 
@@ -407,6 +407,8 @@ Rulesets must include version metadata where possible.
 
 Do not mix Vanilla and Resurrection observations without explicitly labeling them.
 
+V4 covers Sekiro Vanilla only. Resurrection work is deferred until after `v4.0.0` (see "Deferred — Resurrection Mapping" below), but every dataset keeps its ruleset label so Resurrection can be added later.
+
 ---
 
 ## 2. Character Identity
@@ -693,37 +695,7 @@ The objective is to make unexplained combat-relevant actions approach zero for t
 
 ---
 
-# V4 Milestone 6 — Resurrection Mapping
-
-After Vanilla Genichiro is understood, analyze the Resurrection variant.
-
-Treat Resurrection as a separate ruleset.
-
-Use the mod override files as a differential clue:
-
-```text
-Vanilla
-   ↓
-Compare
-   ↓
-Resurrection Override
-```
-
-Classify moves/actions as:
-
-```text
-unchanged
-modified
-new_in_resurrection
-vanilla_only
-shared_semantic_move_with_different_engine_sequence
-```
-
-Do not mix Resurrection training examples with Vanilla examples without ruleset labels.
-
----
-
-# V4 Milestone 7 — Product Integration
+# V4 Milestone 6 — Product Integration
 
 Once the ground-truth schema is stable enough:
 
@@ -749,8 +721,40 @@ Do not introduce them until actual research demonstrates the required cardinalit
 
 ---
 
+# V4 Milestone 7 — Public Deployment
+
+Public deployment moves here from V3.
+
+Deployment should happen only after:
+
+- authentication is stable
+- personal data isolation is tested
+- bilingual UI works
+- the application clearly distinguishes verified vs. uncertain combat content
+- at least one complete ground-truth vertical slice is integrated
+- database migration strategy is stable
+- `attempts.user_id` is made NOT NULL, after confirming no ownerless pre-account attempts remain
+
+Production concerns include:
+
+- HTTPS
+- production PostgreSQL
+- environment secrets
+- database backups
+- migration execution
+- secure cookies
+- deployment from `main`
+- recovery procedures
+- observability appropriate to the actual hosting environment
+
+Do not introduce infrastructure that is not required by the selected deployment platform.
+
+---
+
 # V4 Milestone 8 — Expand Boss-by-Boss
 
+Starts after `v4.0.0` (see the release strategy below).
+
 After the Genichiro pipeline is proven, expand systematically.
 
 Prioritize bosses that exercise different combat structures, for example:
@@ -781,33 +785,35 @@ Do not return to Wiki-only bulk content expansion.
 
 ---
 
-# V4 Milestone 9 — Public Deployment
+# Deferred — Resurrection Mapping
 
-Public deployment moves here from V3.
+Not part of V4's vanilla milestones. It starts after `v4.0.0`; whether in a v4.x release or after V5 is the project owner's decision.
 
-Deployment should happen only after:
+Once Vanilla Genichiro is understood, analyze the Resurrection variant.
 
-- authentication is stable
-- personal data isolation is tested
-- bilingual UI works
-- the application clearly distinguishes verified vs. uncertain combat content
-- at least one complete ground-truth vertical slice is integrated
-- database migration strategy is stable
-- `attempts.user_id` is made NOT NULL, after confirming no ownerless pre-account attempts remain
+Treat Resurrection as a separate ruleset.
 
-Production concerns include:
+Use the mod override files as a differential clue:
 
-- HTTPS
-- production PostgreSQL
-- environment secrets
-- database backups
-- migration execution
-- secure cookies
-- deployment from `main`
-- recovery procedures
-- observability appropriate to the actual hosting environment
+```text
+Vanilla
+   ↓
+Compare
+   ↓
+Resurrection Override
+```
 
-Do not introduce infrastructure that is not required by the selected deployment platform.
+Classify moves/actions as:
+
+```text
+unchanged
+modified
+new_in_resurrection
+vanilla_only
+shared_semantic_move_with_different_engine_sequence
+```
+
+Do not mix Resurrection training examples with Vanilla examples without ruleset labels.
 
 ---
 
@@ -842,6 +848,8 @@ Each release can add additional verified bosses.
 
 This prevents ground-truth completeness from becoming an unbounded release blocker.
 
+Resurrection is not part of `v4.0.0` (see "Deferred — Resurrection Mapping").
+
 ---
 
 # V5 — Automated Gameplay Analysis