Deep issue with Goclaw codebase in general + technical debt

This is me personally writing this issue and not Claude or an other AI agent. As I don't know where to discuss about it, here I am venting in an issue.

A bit like #1283, as I'm going deeper into the codebase and hiting weird bugs, I can't help but notice that so many features of Goclaw had just never had been tested. Such as multi-tennants.

I love the Goclaw end result architecture and implementation, but it's hard for me to reach the point where Goclaw features do perform as expected. Right now I'm struggling getting the good system prompt, the number of fixes on my sandbox is getter larger and larger. and most of the time, the issue is clearly coming from vibe coding practices, such as:

• multiple implementation of the same features in different places in the codebase leading to divergence in their output
• database that is not really normalized
• decision choices from the early version of goclaw that are kept for comptability but that bring complexity and inefficiency, which true cost is hidden behind coding agents. such as the skill system (loaded from files vs. loaded from database).

Gocrawl could be a fully functional great software that deliver what it promised. but right now it's more theoritical.

If I'm struggling as a fullstack developer with 30 years of experience in software development, constantly trying to figure why features do not work as expected. I can't imagine a low tech business owner using it.

Personally, if I had to maintain goclaw, I would drop SQlite (this is actually killing hermes, as the database constantly get corrupted), at least goclaw is in golang, so there is less likely concurrency issues.... but still.
And I would migrate to a docker first architecture, where agents all execute tools in "plugins" (docker containers).
Have a single implementation of everything. High test coverage. Remove technical debt, improve reliability. cleanup the database heavily before doing an other release.

Thanks for listening.

No specific files, tests, or entry points are named. Start by breaking the reported concerns into separate, scoped issues around testing, duplicated implementations, database normalization, skill loading, and SQLite reliability; the issue does not define a completion condition.