GitHub Issue

Feature request: project structure improvement

Discovered On May 31, 2026
Primary Metric open
So, I wanted to dive into this, but honestly for longer community maintained development this seems like an absolute hassle. Why not get a little bit of inspiration from e.g. https://github.com/unslothai/unsloth/tree/main/studio and then connect relevant services together instead of having 30 modules in a directory? This can work for fully agentic development but I still believe there is a good reason for having a little bit of isolation around here. Example for everything: -> why do we have source directory with separate services and core and mcp servers and routes? Why is there no clear distinction between what's frontend, what's backend? I skimmed static directory and it seems like that's where the actual frontend code lives which is.. mildly confusing. If so, why plain JS and how are we handling state without loosing our minds? No wonder one of "todos" is to improve visibility. I think making the repo more maintainable so further people can build on it should be a first step before it'll become even messier. I am happy to give guidance/work on it, if maintainer hits me up. Obviously such refactor would mean most of the PRs before it are gonna be rendered moot. I am writing this not as a jab, but as someone who wants to send patches but got stunned by the structure :D
View Raw Thread

Developer & User Discourse

tadeasf • May 31, 2026
obviously there are other things connected to it that other people mentioned:
-> uv instead of reqs.txt
-> docker-compose in its current state won't play nice on fedora or any other SElinux distro
-> typescript + bun/pnpm. the frontend imo needs a lot of work. imo shadcn with the new admin panels could be easy simple way out? + deciding how we manage state

make those architectural decisions conciously, and then move forward. I'd write tech design doc first, decide which technology to use and why and get into refactoring, so it uses industry standards and best practices and it's easy to navigate
tadeasf • May 31, 2026
thinking about it, regarding the agent harness, I'd likely rather go with pi route and build on top of it rather than having something as heavy and potentially messy as opencode. especially cuz most people won't be able to use, say, more than 2-3 mcp servers due to running model on 16gb vram tops.
NicholaiVogel • May 31, 2026
> I think making the repo more maintainable so further people can build on it should be a first step before it'll become even messier.

I second this, but it may take a lot of coordination upstream, not sure how this will work. I'm here and I'm eager to help in any way that I can.
tadeasf • May 31, 2026
> > I think making the repo more maintainable so further people can build on it should be a first step before it'll become even messier.
>
> I second this, but it may take a lot of coordination upstream, not sure how this will work. I'm here and I'm eager to help in any way that I can.

that's why I am saying that the maintainer @pewdiepie-archdaemon ? someone else? has to drive this change, pick his maintainers and setup a workflow. I'm happy to help but this has to be a priority. I can't imagine doing any serious work on this in its current state. The mess is too large tbh.
NicholaiVogel • May 31, 2026
> > > I think making the repo more maintainable so further people can build on it should be a first step before it'll become even messier.
> >
> >
> > I second this, but it may take a lot of coordination upstream, not sure how this will work. I'm here and I'm eager to help in any way that I can.
>
> that's why I am saying that the maintainer [@pewdiepie-archdaemon](https://github.com/pewdiepie-archdaemon) ? someone else? has to drive this change, pick his maintainers and setup a workflow. I'm happy to help but this has to be a priority. I can't imagine doing any serious work on this in its current state. The mess is too large tbh.

Rooting for Felix to lock in here.