It is organized to match the life-cycle:

• event to set the whole view of a specific form-id
• fn to write the parts CMs to set the parts view of the whole
• event to transact changes (keystrokes) on the whole form
• fn to ripple out change to appropriate parts
• event to transact changes (keystrokes) on any of the form parts
• fn to reflect back the part change to whole

• Make data persistent and recursively hashing
• Use events/defn as a model for working with single and multi-arity parts.
• Look to simplify. It seems complex atm but after doing events/ns I'm hoping to find some patterns that can be shared.

• side-effect refactoring for supported forms

• use consistently throughout the code
• have all common data in the shared ns?? (thinking yes)

• event to persist changes at user behest
• event to persist changes when the form under inspection is changed

• event to set that warnings exist
• use a 'humane' lib to expose the spec warnings
• persist warnings with changes

Goal is to accept changes to the data we call code, persist the changes and offer a variety of feedback.

The server part exposes a shared PREPL, accessible via a web socket.

A limited set of commands will be supported on the socket:

• save
• eval
• xform - see AOP document

shadow-cljs watch repl-ui # UI
clojure -M:clj:server     # Server