diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt
index e3505fd7..0ce8fe2e 100644
--- a/ayanova/devdocs/todo.txt
+++ b/ayanova/devdocs/todo.txt
@@ -7,6 +7,28 @@ todo: Administration - Attached files manager
 	replicate v7
 	add Attachments checker job that checks on demand all files and stuff as per below 
 
+	What can go wrong:
+		Attachment files are accidentally directly deleted or db restored and not files resulting in bunch of fileattachment records with links to non-existent files
+			SWEEPER JOB
+				Flags these as non-existent so user can see that in UI and figure out how to fix it, by restoring the file or deleting the attachment record
+		DB records are deleted but file remains (orphaned)
+			SWEEPER JOB
+				Attaches these files to the NOTYPE object
+		FOREIGN FILES placed in folder directly outside of attachment system
+			user thinks they can just drop them in or accidentally copies them here
+			Or, user renames a folder for some reason?
+				This is a good reason not to delete them, because they can just un-rename them to fix it
+			SWEEPER JOB
+				I think it should delete them outright, but maybe that's a bad idea, not sure
+				ID them to see if they *should* be one of ours by the file name I guess since it's the only identifying characteristic
+					is it in the correct folder which is named based on it's hash?
+					Is it X characters long (they all are or not?)
+					Does it have an extension?  None of ours have an extension
+
+
+
+
+
 		EXISTENCE CHECK
 			iterate FileAttachment records, if physically present then flag as such
 			make sure it has a short circuit that if there are NO files physically then all are out of sync
@@ -19,24 +41,38 @@ todo: Administration - Attached files manager
 		DE-ORPHANIZE ACTION
 			iterate orphaned file attachments to NOTHING type, if found to be attached to any other object remove the orphaned object attachement
 
+		FOREIGN FILES ACTION
+			Delete them silently too bad so sad :(
+				Or, move them out of the structure into the temp folder?  Hmm...
+				Or, just issue a warning notification or report?
+
+
+	TESTING:
+		Delete a file that's been attached in windows
+		Drop a file that was 
 		
 	add sync status to db table so can show in grid
 
 	make a datalist to return this
-	delete selected files from dbmanager
+	DELETE bulk OP
+		delete selected file Attachments db record and physical file if present or just the fileAttachment if missing the physical file
+		This is how you fix broken missing file links, because it's bulk it's not too onerous
+
+
 	download file from dbmanager
 	rename?
 	open attached object 
 	show icon of object type in grid
 	show full physical path and name	
 		(going to be hella long)
-	Move attachment bulk op
+	MOVE bulk op
 		Select one ore more files then select MOVE
 			UI pops up to select object type and manually type in the id
 			it then checks to see that that object exists before moving them to it
 
+
 	
-todo: widget form now always dirty for some fucking reason, fuck this shit, fuck.
+todo: BUG widget form now always dirty for some fucking reason, fuck this shit, fuck.
 
 
 todo: Administration - History