diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt
index e688e848..9419488e 100644
--- a/ayanova/devdocs/todo.txt
+++ b/ayanova/devdocs/todo.txt
@@ -94,6 +94,7 @@ todo: PLANNING WORKORDER considerations:
 		Rest are all related to length of fields, required fields, date order etc and only a few of those to boot
 		Looks like this is not an issue regarding v7 stuff at all
 
+
 	DEPENDENCIES
 		Workorder is not dependent on it's children for anything
 		WoItem is not dependent on any of it's children
@@ -129,11 +130,21 @@ todo: PLANNING WORKORDER considerations:
 				How to do CRUD efficiently with a workorder and client?
 			
 				
-				PROPOSAL: 
-				CREATE:
+				PROPOSAL TO TEST: 
+					Create enough of a graph to test, 3 layers two grandhild collections should be sufficient:
+						WO
+							WOITEMS
+								WOITEMLABORS
+								WOITEMPARTS
+
+				CREATE (POST):
 					CreateFromxxxx routes (NO TEST REQUIRED)
-					POST accepts workorder full graph (test)
-				UPDATE: Send only changes in whole graph from client with an OP (for "operation") flag at each level indicating to change that part or not, a flag?
+					POST accepts NEW workorder full graph (test)
+				RETRIEVE (GET):
+					Get(id) - simple get, just confirm entire graph comes across
+					GetByRelative(ayatype, id) (no test required)
+
+				UPDATE (PATCH): Send only changes in whole graph from client with an OP (for "operation") flag at each level indicating to change that part or not, a flag?
 					WO (OP flag=no change, no concurrency token, basically empty but for the fields that hold the descendents that are changed)
 						woitem 0 (OP flag="Delete" and concurrency token, no other data with it, just the id and flag and ctoken)
 						woitem 1 (OP flag ="update", all fields as in a "put" operation, nothing left out, assumed all are changed)
@@ -145,6 +156,9 @@ todo: PLANNING WORKORDER considerations:
 						Server accepts graph at single WO POST route (since it's not a put)
 					UI
 						ui manufactures the return object with the OP fields by doing dirty tracking on changes
+				DELETE
+					Not much here except handling delete will be more intensive and sophisticated when have real data but for now if the graph deletes then that's enough
+					Test how to delete graph without ref. integrity errors
 
 
 	UI