@@ -139,7 +139,7 @@ V4 Milestone 1 is done, and Milestone 2 has proven the runtime bridge for castle
 
 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 7.
+Public deployment is part of V5: it waits until a user can upload a recording and see which moves caused their failures (section 33).
 
 V4 covers vanilla Sekiro only. All Resurrection mod work is deferred until after `v4.0.0` (section 35).
 
@@ -1105,6 +1105,7 @@ Only after the research schema stabilizes:
 - improve phase mappings
 - sync verified semantic content
 - preserve attempt foreign-key integrity
+- make `attempts.user_id` 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.
 - consider adding ruleset support
 - consider adding engine-action mappings
 
@@ -1123,19 +1124,20 @@ Let the actual research data determine the relational model.
 
 ---
 
-# 33. V4 Milestone 7 — Public Deployment
+# 33. Public Deployment (V5)
 
-Public deployment is intentionally deferred until V4.
+Public deployment moved from V4 to V5 (owner decision, 2026-10-12). The public product starts with the end-to-end flow: a user uploads a recording and sees their failures and the moves that caused them. It comes right after the video upload and failure report (section 38).
 
 Before deployment ensure:
 
+- the upload → failure report flow works and has passed reliability validation
 - authentication works reliably
-- user isolation is tested
+- user isolation is tested, uploaded recordings included
 - 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.
+
+Rehearse with a private deployment once the upload work begins. A small invite-only deployment is fine if outside feedback is needed sooner.
 
 Production concerns may include:
 
@@ -1148,14 +1150,18 @@ Production concerns may include:
 - deployment workflow
 - logging
 - recovery
+- object storage for uploaded recordings
+- background processing for video analysis, and its cost
+- upload size limits
+- retention and privacy rules for users' recordings
 
 Choose infrastructure based on actual hosting requirements.
 
 Do not introduce Kubernetes by default.
 
 ---
 
-# 34. V4 Milestone 8 — Boss Expansion
+# 34. V4 Milestone 7 — Boss Expansion
 
 Starts after `v4.0.0` (section 36).
 
@@ -1214,11 +1220,13 @@ Recommended `v4.0.0` target:
 ```text
 Genichiro ground-truth pipeline proven
 +
-verified production integration
+castle Genichiro move catalog confirmed by the project owner
 +
-stable public deployment
+verified production integration
 ```
 
+Public deployment is not part of `v4.0.0`; it comes in V5 (section 33).
+
 Then expand boss coverage through:
 
 ```text
@@ -1271,10 +1279,11 @@ Use:
     → look back → identify the move → merge one failure → failure report)
 2. Reliability validation on independent recordings
 3. Video upload and failure report (failure counts per move)
-4. Whole-fight move detection (short clips first, then temporal segmentation)
-5. Player-response detection
-6. True per-move analytics
-7. Recommendations
+4. Public deployment (section 33)
+5. Whole-fight move detection (short clips first, then temporal segmentation)
+6. Player-response detection
+7. True per-move analytics
+8. Recommendations
 ```
 
 At first the system proposes move candidates and a person confirms them. Recordings made with the dev-menu overlay are labelled reference data; mask the overlay when training or evaluating.
@@ -1616,11 +1625,10 @@ V3 is released. V4 order:
 Then, to complete `v4.0.0`:
 
 ```text
-6. Product integration (V4 Milestone 6)
-7. Public deployment (V4 Milestone 7)
+5. Product integration (V4 Milestone 6)
 ```
 
-Boss expansion (V4 Milestone 8) follows in v4.1.x. Resurrection is deferred until after `v4.0.0` (section 35).
+Boss expansion (V4 Milestone 7) follows in v4.1.x. Public deployment comes in V5, after the upload → failure report flow works (section 33). 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 6.
 
 
@@ -181,7 +181,7 @@ V2 runs locally with Docker Compose.
 
 #### Deferred or Skipped
 
-* **Public deployment** was deferred: without accounts, a public instance would let anyone record attempts. V3 adds accounts, and public hosting is now planned for V4, once boss content is backed by verified game data.
+* **Public deployment** was deferred: without accounts, a public instance would let anyone record attempts. V3 adds accounts. Public hosting is now planned for V5, once a player can upload a recording and see which moves caused their failures.
 * **Boss search and filtering** was skipped, because 8 bosses fit comfortably on one page.
 
 ---
@@ -211,13 +211,13 @@ The full plan is in [ROADMAP.md](ROADMAP.md). In short:
 V1  What killed me?                      → manual attempt analytics
 V2  Where am I improving or struggling?  → structured relational analytics
 V3  Can different players use it?        → multi-user product foundation
-V4  What moves actually exist?           → combat ground truth + public deployment
-V5  What happened in the fight?          → gameplay video analysis
+V4  What moves actually exist?           → combat ground truth
+V5  What happened in the fight?          → gameplay video analysis + public deployment
 V6  Can this work across games?          → multi-game platform
 ```
 
-* **V4** builds verified boss data from the game itself, through runtime instrumentation and targeted reverse engineering, starting with Genichiro. The app is then deployed publicly.
-* **V5** analyzes uploaded gameplay to detect boss moves and player responses. Knowing how often each move actually occurred makes true per-move success rates and practice recommendations possible.
+* **V4** builds verified boss data from the game itself, through runtime instrumentation and targeted reverse engineering, starting with Genichiro.
+* **V5** analyzes uploaded gameplay, starting with the failures in a recording and the moves that caused them; the app is deployed publicly once that works. It then detects every boss move and the player's responses. Knowing how often each move actually occurred makes true per-move success rates and practice recommendations possible.
 * **V6** extends the platform beyond Sekiro, starting with Black Myth: Wukong.
 
 The long-term goal is to turn gameplay footage into trustworthy, explainable boss-practice analytics with as little manual input as possible.
 
@@ -181,7 +181,7 @@ V2 使用 Docker Compose 在本地运行。
 
 #### 推迟或跳过的内容
 
-* **公网部署**被推迟了：在没有账号系统的情况下，公开的实例会让任何人都能新增攻略记录。V3 加入了账号系统；公网部署现在计划放在 V4，等 Boss 数据经过游戏本身的验证之后再进行。
+* **公网部署**被推迟了：在没有账号系统的情况下，公开的实例会让任何人都能新增攻略记录。V3 加入了账号系统；公网部署现在计划放在 V5，等玩家上传录像后能看到是哪些招式导致了失误，再进行。
 * **Boss 搜索和筛选**被跳过了，因为 8 个 Boss 在一个页面上就能放得下。
 
 ---
@@ -211,13 +211,13 @@ V3 把单用户的本地应用，变成可以供多名玩家使用、每人数
 V1  是什么打败了我？         → 手动记录的尝试分析
 V2  我在哪里进步、在哪里卡住？ → 结构化的关系型分析
 V3  不同玩家都能用吗？       → 多用户产品基础
-V4  到底有哪些招式？         → 战斗真实数据 + 公网部署
-V5  这场战斗里发生了什么？   → 实战录像分析
+V4  到底有哪些招式？         → 战斗真实数据
+V5  这场战斗里发生了什么？   → 实战录像分析 + 公网部署
 V6  能用于其他游戏吗？       → 多游戏平台
 ```
 
-* **V4** 通过运行时监测和有针对性的逆向工程，从游戏本身建立经过验证的 Boss 数据，先从苇名弦一郎开始；之后再进行公网部署。
-* **V5** 分析上传的实战录像，识别 Boss 招式和玩家的应对。知道每个招式实际出现了多少次，才能算出真正的招式成功率，并给出练习建议。
+* **V4** 通过运行时监测和有针对性的逆向工程，从游戏本身建立经过验证的 Boss 数据，先从苇名弦一郎开始。
+* **V5** 分析上传的实战录像，先找出录像里的失误以及导致失误的招式；这一步跑通后进行公网部署。之后再识别全部 Boss 招式和玩家的应对。知道每个招式实际出现了多少次，才能算出真正的招式成功率，并给出练习建议。
 * **V6** 把平台扩展到只狼以外的游戏，第一个是黑神话：悟空。
 
 长期目标是：把实战录像变成可信、可解释的 Boss 练习分析，并尽量减少玩家的手动输入。
 
@@ -739,6 +739,7 @@ Once the ground-truth schema is stable enough:
 - expose provenance where useful
 - optionally expose verification status internally
 - preserve existing attempt references safely
+- make `attempts.user_id` NOT NULL through a migration, after confirming no ownerless pre-account attempts remain
 
 Only now should production schema changes for engine-action mappings be considered.
 
@@ -755,37 +756,7 @@ 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
+# V4 Milestone 7 — Expand Boss-by-Boss
 
 Starts after `v4.0.0` (see the release strategy below).
 
@@ -862,13 +833,13 @@ v4.0.0
 =
 ground-truth pipeline proven
 +
-Genichiro complete vertical slice
+castle Genichiro move catalog confirmed by the project owner
 +
 production integration
-+
-public deployment
 ```
 
+Public deployment is not part of V4. It waits for the V5 end-to-end flow, where a user uploads a recording and sees which moves caused their failures (V5 Milestone 4).
+
 Then expand verified coverage incrementally:
 
 ```text
@@ -978,7 +949,42 @@ PostgreSQL should store metadata and references.
 
 ---
 
-## V5 Milestone 4 — Automatic Move Detection
+## V5 Milestone 4 — Public Deployment
+
+Public deployment moves here from V4. The public product starts with the end-to-end flow: a user uploads a recording and sees their failures and the moves that caused them.
+
+Deploy only after:
+
+- the upload → failure report flow works and has passed reliability validation (Milestones 1–3)
+- authentication is stable
+- personal data isolation is tested, uploaded recordings included
+- bilingual UI works
+- the application clearly distinguishes verified vs. uncertain combat content
+- database migration strategy is stable
+
+Rehearse first: once Milestone 3 work begins, deploy privately so hosting problems surface early. A small invite-only deployment is fine if outside feedback is needed sooner.
+
+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
+- object storage for uploaded recordings
+- background processing for video analysis, and its cost
+- upload size limits
+- retention and privacy rules for users' recordings
+
+Choose hosting from these actual requirements. Do not introduce infrastructure that is not required by the selected deployment platform.
+
+---
+
+## V5 Milestone 5 — Automatic Move Detection
 
 Detect every boss move in a fight, not only the ones before a failure. Move occurrences are the denominator that true per-move rates need.
 
@@ -1001,7 +1007,7 @@ Expand coverage from what the system could not attribute in users' recordings: a
 
 ---
 
-## V5 Milestone 5 — Player Response Detection
+## V5 Milestone 6 — Player Response Detection
 
 Detect or infer responses such as:
 
@@ -1018,7 +1024,7 @@ Only calculate metrics supported by observed events.
 
 ---
 
-## V5 Milestone 6 — True Per-Move Analytics
+## V5 Milestone 7 — True Per-Move Analytics
 
 Once move occurrences and outcomes are observable:
 
@@ -1036,7 +1042,7 @@ This is fundamentally different from V1–V3 failure-count analytics.
 
 ---
 
-## V5 Milestone 7 — Practice Recommendations
+## V5 Milestone 8 — Practice Recommendations
 
 Practice recommendations move here from the old V3 roadmap.
 
@@ -1126,11 +1132,11 @@ Can different players reliably use it?
 
 V4
 What moves actually exist?
-→ Combat ground truth + public product
+→ Combat ground truth
 
 V5
 What happened in the fight automatically?
-→ Video / CV gameplay analysis
+→ Video / CV gameplay analysis + public product
 
 V6
 Can this work across games?