diff --git a/Crusader.rep/projectState b/Crusader.rep/projectState
index 2d71cb8..6244408 100644
--- a/Crusader.rep/projectState
+++ b/Crusader.rep/projectState
@@ -3,524 +3,13 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
diff --git a/Crusader.rep/user/00/~00000008.db/db.23.gbf b/Crusader.rep/user/00/~00000008.db/db.25.gbf
similarity index 99%
rename from Crusader.rep/user/00/~00000008.db/db.23.gbf
rename to Crusader.rep/user/00/~00000008.db/db.25.gbf
index d669781..f1a68fd 100644
Binary files a/Crusader.rep/user/00/~00000008.db/db.23.gbf and b/Crusader.rep/user/00/~00000008.db/db.25.gbf differ
diff --git a/Crusader.rep/user/~index.dat b/Crusader.rep/user/~index.dat
index 82c5f5a..35d5aa2 100644
--- a/Crusader.rep/user/~index.dat
+++ b/Crusader.rep/user/~index.dat
@@ -5,6 +5,7 @@ VERSION=1
00000008:udf_c0a86451c28c202638381579400:c0a86451f608205075819887000
0000000b:udf_c0a86451c28e202638509414500:ac18b01ab332438409229485800
0000000d:udf_c0a86451c52a19721794868600:c0a86451c52b19721868788800
+ 0000000e:udf_c0a86451da1a44983408575900:c0a86451da1b44983455342000
00000006:udf_c0a86451f2583322595358500:c0a86451c1883616844258300
00000009:udf_c0a86451f6e9206725659389900:c0a86451ed04206884877489100
00000007:udf_c0a86451fc492611033559300:c0a86451cb1215992032385300
@@ -14,5 +15,5 @@ VERSION=1
00000000:udf_c0a8647bf0178892741854800:c0a8647bd36236342207469100
00000001:udf_c0a8647bf4b212984786819600:c0a8647bd36336342224113900
00000003:udf_c0a8647bfe7615910786193500:c0a8647bd36536342248279100
-NEXT-ID:e
+NEXT-ID:f
MD5:d41d8cd98f00b204e9800998ecf8427e
diff --git a/Crusader.rep/user/~journal.dat b/Crusader.rep/user/~journal.dat
deleted file mode 100644
index d747a02..0000000
--- a/Crusader.rep/user/~journal.dat
+++ /dev/null
@@ -1,2 +0,0 @@
-IADD:0000000e:/udf_c0a86451da1a44983408575900
-IDSET:/udf_c0a86451da1a44983408575900:c0a86451da1b44983455342000
diff --git a/docs/map_renderer/vue-refactor-plan.md b/docs/map_renderer/vue-refactor-plan.md
index 7259694..51360ce 100644
--- a/docs/map_renderer/vue-refactor-plan.md
+++ b/docs/map_renderer/vue-refactor-plan.md
@@ -21,6 +21,31 @@ The renderer already has a useful split between source files and deployment arti
That means the migration should be an incremental extraction, not a from-scratch rewrite.
+## Current State Re-evaluation
+
+The earlier Phase 2 checkpoint is now outdated. The renderer has moved further in both the rendering pipeline and the runtime split, but the Vue migration is still only partial.
+
+### What is true now
+
+- The viewer is already atlas-and-scene driven rather than a single baked raster surface.
+- Static export, normal dynamic viewing, and explicit admin catalog-editing modes already exist.
+- The Vue shell is no longer just one root component; it now owns the side panel, viewport shell, tooltip mount, and egg editor modal markup.
+- The active browser runtime now enters through the Vue shell and Vue controller modules under `map_renderer/src/vue`.
+- The old public browser coordinator files have been removed from `map_renderer/src/public`.
+- Catalog editing works today, but until this update it still rendered through legacy `innerHTML` tooltip markup instead of a Vue-managed editor surface.
+
+### Main architectural gap before this update
+
+- Runtime mode selection existed functionally, but static versus dynamic behavior was still chosen through scattered helper checks and hard-coded URL branches across the legacy modules.
+- The pinned tooltip and catalog editor were still procedural DOM output, which meant Phase 4 behavior existed without actually being migrated into Vue.
+
+### Main architectural gap after this update
+
+- Vue now owns the tooltip/editor surface, but the legacy app still computes most tooltip content and still owns the underlying editor actions.
+- Runtime mode and data-path selection are now centralized, but higher-level shared state is still concentrated in the legacy `app.js` entrypoint rather than in composables or services.
+- The remaining heavy work is no longer removing the old public bootstrap; that is done.
+- The remaining heavy work is deeper cleanup: extracting the large Vue controller into smaller composables/services and replacing the remaining imperative DOM coordination inside that controller with more idiomatic Vue state flow.
+
## Non-Negotiable Requirements
1. Keep a static deployable build that can run from committed artifacts with no file-system write capability.
@@ -128,6 +153,15 @@ Deliverable:
- The same Vue UI can run in both modes without leaking write capability into static builds.
+### Phase 3 Status
+
+- Completed earlier: the runtime already supported both static exported scenes and dynamic live-build scenes from one codebase.
+- Completed in this batch: the client now has a shared runtime adapter layer that centralizes mode detection, capability checks, and data-path selection for catalog data, scene data, atlases, and NPC spawner metadata.
+- Completed in this batch: the legacy browser modules no longer hard-code most static-versus-dynamic URL branching inline; they consume the shared adapter instead.
+- Completed in this batch: the active runtime controller moved under `src/vue/controller`, so the browser no longer boots through the old `src/public/app.js` path.
+- Result: the mode boundary is now explicit in code and reusable from both Vue-facing and legacy-facing modules.
+- Remaining: move more page-level behavior from the Vue controller into smaller Vue-aware composables so the app shell owns mode/config decisions through smaller units rather than one large controller module.
+
### Phase 4: Migrate Catalog editing carefully
Goal: preserve catalog edit power while moving to Vue.
@@ -142,6 +176,15 @@ Deliverable:
- Catalog editing works in dynamic mode and is unreachable in static mode.
+### Phase 4 Status
+
+- Completed earlier: catalog editing stayed admin-only and the write path already updated CSV-backed catalog data.
+- Completed in this batch: the pinned tooltip and catalog editor form now render through the Vue tooltip component instead of legacy `innerHTML` generation.
+- Completed in this batch: save, hide, warp-copy, egg-edit launch, and monster-spawner action hooks now cross the Vue boundary through an explicit tooltip bridge instead of ad hoc DOM listeners on generated markup.
+- Completed in this batch: static export now uses the Vue production shell as its site base instead of the removed public browser shell.
+- Result: the highest-value editable UI path is now under Vue control while preserving the existing catalog save and rebuild behavior.
+- Remaining: migrate more editor-adjacent state and panel behavior out of the legacy coordinator so the catalog workflow no longer depends on direct DOM querying for the broader side-panel experience.
+
### Phase 5: Clean up the old entrypoint
Goal: remove dead code and simplify maintenance.
@@ -276,6 +319,25 @@ The refactor is complete when all of the following are true:
- The root Vue app now composes those feature components instead of keeping the entire shell in one template file.
- The default local runtime path now serves the Vue build when it exists, so the componentized shell is the main entry for dev and admin modes.
+### Phase 3 Progress
+
+- Static export, dynamic live-build mode, and admin catalog-editing mode all continue to run from one application codebase.
+- Runtime mode and capability checks are now centralized in a shared adapter module instead of being spread through multiple legacy helpers.
+- Scene, atlas, catalog, and NPC-spawner data access now flow through the shared adapter boundary.
+- This makes the read-only versus writable split explicit and reduces the risk of accidentally leaking admin-only paths into static mode.
+- The old public coordinator files (`app.js`, DOM registry, UI control wrapper, map catalog UI wrapper, modal wrapper, and public state module) have been removed.
+- The active controller now lives in `map_renderer/src/vue/controller/renderer-app.js` and is loaded from the Vue app shell.
+
+### Phase 4 Progress
+
+- The Vue tooltip component now owns the pinned tooltip and catalog editor presentation.
+- Catalog editing controls are no longer assembled as legacy tooltip HTML strings.
+- The legacy renderer still prepares tooltip metadata and executes save/rebuild actions, but those actions are now invoked from Vue through a bridge rather than direct listeners on generated DOM.
+- Static mode remains read-only because the runtime adapter and site config still gate write capability before the editor can appear.
+- The static export base shell now comes from the Vue build output rather than the deprecated source public shell.
+
## Final Notes
The best outcome here is not a perfect one-shot rewrite. It is a controlled migration that keeps the current app working, makes the static and dynamic deployment split explicit, and steadily moves the renderer toward a maintainable Vue architecture.
+
+The next meaningful milestone is no longer “get Vue on the page.” That is already done. The next milestone is to keep shrinking the legacy coordinator by moving shared viewer state, side-panel workflows, and editor affordances into Vue composables and components without regressing the atlas-scene viewer or the admin-only catalog workflow.