For project 3 I'm not sure I understand what you want done. Because centralized update systems with scattered various scripts taking direction from the centralized update system is done a lot and is not hard to implement.
The simplest solution is to have a place on the network where updates are posted. As soon as a script sees there is an update it makes changes and if successful to reports back to this central location it received the update and implemented it. The person in charge can then see what has been updated.
Depending on your needs you can make a dynamic script that can take directions and update or reconfigure itself. That is a lot more complicated to implement. The more common way is for a script to discover an update exists and calls another script to update itself. The update script moves the old script to the trash, and puts the new script in it's place. You can also write a script that can create a brand new script on the fly and just dynamically generate AppleScript code (inserting anything that is specific to a particular script), then put it into into a script file and save it to where the old script was with the same name as the old one. This is the method I've done most often.
Of course moving scripts or saving scripts requires the script be able to handle the network permissions. But Applescript has ways to do that.
There are a lot of ways to go about this kind of stuff. Without more specifics there are are just too many ways to implement this for me to describe them all.
The overall idea is that you decide if you want scripts handling events in many location and controlled from a central location or if you want a centralized script that handles Macs in many different places. The centralized script that does everything from one place suffers from the problem that it breaks a lot when something is changed a the network. And I've seen many people who just change something and not tell the technical person. But having lots of script around suffers from the problem of the technical person having more problems knowing how the various scripts are doing. Especially when the user quits the script, a reboot is required and the script does not restart after the reboot, the script crashes ....
My solution to this last problem is to have a script report every so often that it is still running and I have a central script that tracks which scripts are reporting and which ones have failed to report back. Also I never leave scripts running on a Mac the user can open and read. Sometimes users really like to tinker and that can cause a lot of problems.
I mentioned a lot of things because I don't know your constraints or requirements are.