What you need is a MOO MUD.
You have to disguise it, I suppose. Just make a MUD about process management things.
This will uniformly handle both you authentication needs and long standing-processes. It is only a matter of thinking up the world.
The reason this is my recommendation, is you don't seem to be interested in graphics, you want to cut them out and focus on the marrow. This is a text system.
And, you are facing a massive design challenge, this is many years of work if you want success.
How?
Well, this thing you have here "average=AVERAGE([1,1,2,3,5,8]) ECHO(average)" can become a very large device:
"Refinery is a container, it contains the averaging station, that is connected via pipe to an echoing station...
Or a very tiny device:
"User inventory contains a data pipe named echoAverage. The pipe consists of two parts, a number accumulator, and a number printer. It accepts a list of numbers and immediately returns response."
Now, let me add, you have two ways of thinking about data pipes.
The first way is where each element of a pipe is a well defined program such as "Average", "Echo". Blender has this, they have little boxes for everything you need to wrangle nodes.
And the second way, is synthetic, used in Node.js and the old languages, it is clean, and PVC white. Here you don't have components, can you believe it? No components, pure pipes. So you have, source, destination, tee (splitter), filter (drop packets), transform (map/mangle), and reduce (accumulate, queue).
In the second way you first create a beautiful data network made of tees, filters, reducers and transformers, and then you attach functions, so you would say:
source---->reducer1----transformer1---transformer2---void
and reducer1 function = take 10 nubers, or collect until
transformer1 function is return add values and divide
transformer2 function is echo input value, return perhaps null
So in the first approach you make a network of functions,
and in the second approach you first build pipes and then attach functions.
In the MUD, I would build the pipes first, and then come in with unit tests, which would instantly fail. And then I'd make a thing that lists all the failures, and that would serve as a todo.
Now, authentication specifically, I would go for DOOM, as a heads up, and because it is funny. And when you are logged into the MUD as a developer you can enter IDKFA cheat code and get all the keys.
The reason this is not stupid, is because it is simple, and uses our navigation abilities, memory palace right? And allows you to create the graphic world in your mind, instead of in SVG.
Ask AI to create a simple MUD server for you.
Lot at Notes/Domino screenshots, or any other effort in this area, and how garbage that UI gets, it is UI gore
If you ever created a G-UI for it, it would just be Containers that can contain things (room, inventory) and things (that don't have anything inside, but may have actions, functions)
So, the developer version of your tool might as well be a heads up to Zac McCraken, or King Quest, It can be circles for rooms and lines for doors, but AI gan give you graphics.
If I was doing this, I would go for aliens (https://www.youtube.com/watch?v=efolLO2zcpc) as the UI can show AI generated door, and objects in your MUD.
You can also have an inform 7 Skein, which can be used as a unit test, as it captures moving though the MUD.
A security system can include a feature where hackers get eaten by a Grue, and maybe things from Neuromancer and Snowcrash.
Use an ORM, so you will get long lived processes for free, by default, as a function of the system.
This system is by design, multi-user, you can have many AI working to make the world better. And many developers, if you are that kind of a person.
Go with a regular database, but be mindful of how CouchDB works. The idea of a doc and revision and GUI, is something that would fit the old world where muds were special. It is an eventual consistency storage that you can just rsync folders.
If I was making a MUD I would develop it on Probably a RPI4 or equvalent SBC, but, I would try to see what it would take to get it all going on an RPI Zero ... it is a world of text, it will tell you when your MUD is slow. And when you bring it to modern machines, you can laugh at everybody else's performance.
Can't use Java here, so ANSI C or just something slightly above it, that is almost as fast.
Because you seem to be rejecting graphics, make it fast.
Look at https://en.wikipedia.org/wiki/RAML_(software) for an outside of the world editing perspective, as opposed to working from within the mud.
As to the rest, MUD it is just a colorful https://raw.githubusercontent.com/wiki/webmachine/webmachine... with emergent properties, that makes use of human abilities, such as navigation.
For the naysayers, this is LLM/AI compatible, so it could be a lot less effort than it seems.