Artemis Architecture

[m-truscott]

There are currently a number of refactoring efforts within Artemis with the goal of reducing tech debt, and logically rearranging similar components together.

Current Status

• More library components are being aggregated into sourcekon
• artemis-client contains all client code and is used by most of the intended consumers

One important set of considerations moving forward are:

• What components need to be exposed to packages that the user has access to
• What components are propriety and should be hidden from the user

I'll start with artemis-code-optimiser, diagrams here.

@jose-turintech
In order to make more informative decisions about architecture and repo hierarchy, what is needed?

@grafail
To the above point, my understanding is that we need an idea of how the current system is deployed and what components are dependent on what systems / libraries.

Current Ideas

• Sourcekon is external facing library
• Move treesitter logic to sourcekon
• Merge library logic

Points of Discussion

• Where should the base worker utilities go?
• Where does worker logic go for agents, code-optimiser, artemis-misc, falcon? Can we unify these? (user run workers vs internal workers)
• What is the scaling requirement for various workers? (might deserve a separate thread)
• Custom worker logic needs to be separated from optimisation internals?