QonQrete has moved past the old “three agents in a trench coat” summary. The current project is a file-based, local-first agentic build yard with a real runtime, hardened container execution, deploy-to-workspace flows, and IDE integrations that make it usable without turning your shell history into soup.
The current attached repo shows v1.2.0, and that matters because the project page and post should describe what is actually there now, not some earlier snapshot.
What Ships Today
The repo is not just one CLI script. It currently ships three concrete layers:
The QonQrete core runtime / CLI
A VS Code extension
An IntelliJ / JetBrains plugin
That means the current project story is as much about workspace deployment and operator UX as it is about the inner agent loop.
The Build Loop Still Matters
The heart of the system is still the structured multi-agent loop, but it now sits inside a more serious runtime shape.
TasqLeveler sharpens the task before the main build loop begins.
InstruQtor decomposes the work into briqs and emits the qontract.
ConstruQtor writes and edits code in the qage.
InspeQtor reviews the result and pushes the next correction path.
Qontextor and Qompressor help manage context and structure so runs stay sane over time.
The important bit is that this is all file-based and inspectable. You can actually see what the system is doing instead of trusting invisible state inside a vendor UI.
Why Local-First Still Slaps
The project is built around the idea that your codebase, runtime state, prompts, and execution artifacts should stay on your own machine and inside your own directory structure.
That means:
no random SaaS lock-in by default
no codebase being force-fed to somebody else’s cloud unless you decide so
no mystery state hidden behind an API tab
no loss of control over the actual work products
That local-first position is not just vibe. It shapes the whole architecture.
Hardening the Yard
One of the strongest parts of the repo right now is that QonQrete is designed to run inside a hardened container with dropped capabilities, a non-root runtime, and clear separation between the host workspace and the execution yard.
That is what makes the “safe sandboxes on your own machine” claim feel legit instead of fluffy copy.
Workspace Deployment Changed the Feel
The newer deploy-to-workspace flow is a big deal. Instead of making the user manually clone weird runtime trees or hand-place files, QonQrete now drops itself into .qonqrete/ inside the working project and syncs a root-level tasq.md into the runtime loop.
That makes the system feel like a practical construction yard you can drop next to an existing repo, not a research prototype demanding its own shrine.
Multi-Provider Without Losing the Plot
The repo also shows support for multiple provider backends, including local llama.cpp style setups. That matters because it keeps the project from being hard-wired to one model vendor while still allowing the core file-based runtime and workflow discipline to stay the same.
So yeah: the actual project is bigger and more grounded now than the old simplified blog version suggested. It is still gloriously wonky, but it has moved into a much more honest “real toolchain” phase.