Cleaning Up the AI Salebot: From Chaos to Publication

We’re in that peculiar phase of software development where the code works, the features ship, but the project itself looks like it was assembled by someone who’d never heard of version control. Time to change that.

Our AI Agents Salebot project—a Python-based bot handling everything from API interactions to security—needed serious housekeeping before going public. The task was straightforward: prepare the repository for publication, lock down the documentation, establish proper licensing, and push to GitLab.

The first challenge wasn’t technical—it was philosophical. The project inherited MIT licensing, but we needed copyleft protection. We switched to GPL-3.0, ensuring anyone building on this work would have to open-source their improvements. It’s the kind of decision that takes two minutes to implement but matters for years. We updated the LICENSE file and README with author attribution (Pavel Borisov), making the intellectual property crystal clear.

Next came the cleanup. The .gitignore file was incomplete. We were accidentally tracking internal documentation in docs/archive/, local configuration data in the data/ folder, and massive Vosk speech recognition models that don’t belong in version control. I expanded .gitignore to exclude these directories, then pruned the repository to contain only what mattered: the 17 core Python modules in src/, the test suite, scripts, and documentation templates.

The project structure itself was solid—94 files, nearly 30,000 lines of code, properly organized with clear separation between source, tests, and utilities. We initialized a fresh git repository with SHA-1 object format (the standard), created an initial commit with all essential files, and configured the remote pointing to our GitLab instance.

Here’s where things got interesting: we hit a DNS resolution issue. The GitLab server wasn’t accessible from our network, which meant we couldn’t immediately push upstream. But that’s fine—the local repository was clean and ready. The moment connectivity is restored, a single command (git push --set-upstream origin main) would publish the work.

What we accomplished: A production-ready codebase with proper licensing, clean git history, documented architecture, and clear ownership. The repository is now a solid foundation for collaboration.

Tech fact: Git’s SHA-1 transition is ongoing—newer systems prefer SHA-256, but SHA-1 remains the default for broad compatibility. It’s one of those infrastructure decisions that feels invisible until you’re setting up your first repo on a new server.

The irony? In software, cleanliness pays dividends—but only when you’re patient enough to do it right. And speaking of patience: Java is like Alzheimer’s—it starts off slow, but eventually, your memory is gone. 😄