diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt
index 9419488e..b135ebc9 100644
--- a/ayanova/devdocs/todo.txt
+++ b/ayanova/devdocs/todo.txt
@@ -152,6 +152,10 @@ todo: PLANNING WORKORDER considerations:
 							labor 2 (OP flag = "update" with all data)
 							labor 3 (OP flag="delete" with concurrency token and nothing else)
 							labor 4 (OP flag="Add", with all PUT data)
+					issues with patch:
+						how to post a whole object leaving blank when so many fields will be required?
+						maybe we don't make them required at the object field annotation level but only at the db level and as a biz rule?
+						
 					SERVER
 						Server accepts graph at single WO POST route (since it's not a put)
 					UI
@@ -169,6 +173,22 @@ todo: PLANNING WORKORDER considerations:
 		think Patch
 		CONCURRENCY:
 			if any part of the patch fails the whole patch fails
+
+		idea: UI reflects tentativeness state of object:
+			The UI doesn't imply something is done by changing it fully until the save is completed. 
+			This serves two purposes: 
+				1) user knows at a glance what isn't saved yet and will know it's waiting for save clearly, hopefully leading them to save more often, 
+				2) client doesn't need to track invisible shit behind the scenes, can more easily do patch updates right off UI source
+
+			e.g.:
+			if deleted a row in parts, that row doesn't disappear but rather shows crossed out, maybe grayed out but still there until save to indicate it's tentative status
+			if added a row, shows green or something or bold or asterisk, (can style with css based on state) until saved
+			problems: 
+				how to handle regular fields that are changed (that's a lot of field data to track for changes)?
+					Maybe client keeps a virgin copy of the original wo for comparison
+					periodically does a compare and flags differences on updates?
+					(this would also help to serve as an Undo maybe?)
+
 		
 
 	A biz object for each one?