diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt
index 399cedb3..c8fc5163 100644
--- a/ayanova/devdocs/todo.txt
+++ b/ayanova/devdocs/todo.txt
@@ -26,8 +26,7 @@ Prioritize anything that stands in the way of beta testing
 
 TODO: 
 docs cleanup
-features in immediate block below 
-re-check for testing cases
+
 
 # OUTSTANDING MAJOR AREAS TO BETA
 	
@@ -38,6 +37,12 @@ re-check for testing cases
         internal static decimal AYANOVA_SERVER_TEST_MODE_TZ_OFFSET { get; set; }
         internal static string AYANOVA_SERVER_TEST_MODE_SEEDLEVEL { get; set; }
 
+	this:
+		//CONTENTROOTPATH
+        //** Not intended for end users
+        internal static string AYANOVA_CONTENT_ROOT_PATH { get; set; } //Note: set in startup.cs, not in program.cs as it requires startup IHostingEnvironment
+
+
 	trial / seeder system
 		For beta I don't think this is particularly critical, users will likely jump straight to migration anyway no matter what we tell them to do
 	docs
@@ -507,7 +512,7 @@ todo:3 is there a way to tell if other connections are being used to AyaNova db
 LATER
 ......
 
-todo:21 Changes to allow in place updates of server without erasing data:
+todo:2 Changes to allow in place updates of server without erasing data:
 	(Note: this is a 1 due to probbaly needing some stuff in place (source language) *before* release or it will become a nightmare after release)
 	Needs to be supporting this early as possible so that upon release we can easily make changes without breaking existing setups or forcing complex actions
 	how to add locale keys in future after release without erasing all data?
@@ -518,11 +523,13 @@ todo:21 Changes to allow in place updates of server without erasing data:
 		Stock locales can just be completely replaced at any time, custom ones need a fixup, 
 		Custom locales should include where they came from (which language) so can more easily add new keys
 	Schema updates in place not require full delete
-todo:1 figure out method to determine all translation keys actually used and remove unused ones entirely as they will show in the Translation ui and don't want to confuse people
+todo:2 figure out method to determine all translation keys actually used and remove unused ones entirely as they will show in the Translation ui and don't want to confuse people
 	Note: can do a search in Code editor at client for ay.t( and it will show all the translation keys fetched in code for the most part other than grid columns
 	can click in results and copy all to text which could then be processed to find all unique values??
 	Or, just exercise the whole app and all lists and then can pull from the local cache in the browser!!!
 
+	
+
 todo:3 NOTIFICATION after the fact (PROBABLY JUST DOCUMENT THIS IS HOW IT WORKS)
 	what happens when a user subscribes to a notification after an object was created
 	for example if a unit has a contract and they subscribe to contract expiring they won't get notified about units unless they are edited and saved