The biggest release KongCode has ever shipped has zero new features. Not one. 0.7.74 is a cleanup release, and it changed more about the system than any feature sprint we have done.
There is this thing that happens when you build fast. You are shipping, things work, users are running sessions, the graph is growing. And somewhere along the way the codebase starts accumulating scar tissue. Dead code that was scaffolded fourteen months ago but never got wired up. Orphan records sitting in the database with no edges connecting them to anything. Writers that create rows but never create the relations the schema says are required. You do not notice because the system still works. Until one day the system works despite itself, and that is a different thing entirely.
The waterfall
We ran a 4-stage QA waterfall across the entire codebase. AUDITOR finds the issues. VALIDATOR confirms they are real and not false positives. IMPLEMENTER fixes them. VERIFIER checks the fix did not break anything else. Four passes, each one independent, each one checking the work of the one before it.
It found 55 half-wired graph surface issues. Not hypothetical. Live, on the dev workstation, in a database with real session data.
Seventeen orphan reflections were sitting in the graph with no reflects_on edge connecting them to a session. The writer that created them had been dead code since the coalesced extraction rewrite, but nobody removed it. The enqueuer was gone, the consumer was still there, and the rows it left behind were just... floating. Six got healed by resolving their session IDs. Eleven were unrecoverable and got deleted. Orphan count went from seventeen to zero.
A summarizes relation table had 55 rows in it. No writer existed anywhere in the repo history. These rows came from a pre-fork ancestor of the codebase, survived every migration, and sat there doing nothing for months. The table is gone now.
Same story with tool_result_of. Scaffolded, never registered on the hook bus, zero rows in production. 135 lines of code maintaining an edge type that was never once created. Gone.
The dead code
470 lines of dead source code and 155 lines of dead test code. That is what we removed in this single release. Not deprecated code with a migration path. Dead code. Code with no callers, no enqueuers, no path from any entrypoint.
The thing about dead code is it does not just sit there. It competes for your attention. It shows up in grep results. It makes you think a feature exists when it does not. It makes the codebase feel larger and more complex than it actually is. Every line of dead code is a lie the codebase tells you about itself.
One of the dead files was an entire subagent lifecycle handler for a transport layer we do not ship. Another was a heuristic drain consumer for work types that had been retired two releases ago. The enqueuers left, the consumers stayed behind like furniture in an apartment nobody lives in anymore.
The honest part
We are not database architects. We have never claimed to be. The SurrealDB layer of this project is the part where we were learning as we built, and the git history proves it.
174 commits across 17 days. When you pull them apart by subsystem, a pattern shows up. The daemon lifecycle has 24 commits covering PID locks, idle reaping, version supersession, singleton enforcement. The retrieval pipeline has 48 commits. The extraction pipeline has 46. The ACAN reranker has 18. Those are designed systems with deliberate engineering behind them. The team built those, and the coding agent assisted.
The database layer? Fifteen distinct SurrealQL bugs across the version history. DELETE...LIMIT is not valid SurrealQL and we wrote it anyway. time::unix(NONE) crashes instead of returning null and we did not guard for it. We string-interpolated tag values into queries instead of using parameterized bindings. We declared edge types in the schema and then used different edge types in the writers. We left a summarizes table with 55 rows and no writer for months without noticing. The graphExpand function was running 125 individual SQL statements per hop because we did not know SurrealDB supported multi-edge traversal syntax. That is not engineered. That is learning the database while building the product that depends on it.
But here is the thing. We knew we did not know. Every step of the way we layered human logic on top of what the agent generated. When the schema said a relation needed an IN and OUT type, we checked it against what the writer actually sent. When a query crashed in production, we did not just patch the syntax... we asked why the query existed and whether it should. The 4-stage waterfall that produced 0.7.74 exists because we knew the database layer needed an audit we could not do by feel.
The numbers tell the story honestly. 732 lines of schema. 15,983 lines of engine code. 15,506 lines of tests. The schema is three percent of the codebase. The part we vibe coded is small. The part we engineered is everything around it... the memory system, the daemon architecture, the extraction pipeline, the retrieval intelligence, the security hardening. That is where the 24,000 lines live, and those were built with intent.
The broader sweep
0.7.74 was the cap on a run that started around 0.7.67. Eight releases in about four days... none of them features. Security hardening, graph integrity, performance, and a lot of looking at things we had been ignoring.
The security pass alone covered constant-time auth token comparison, SHA256 verification on every bootstrap download, parameterized SurrealQL replacing string-interpolated queries, prompt injection defense that strips structural XML tags from stored content, and hiding database credentials from /proc by moving them from CLI args to environment variables. Each one of those is the kind of fix where you wonder how it was not already done. The answer is always the same... you were busy shipping features.
The performance pass rewrote graphExpandfrom 125 SQL statements per hop down to 10. That is not a typo. The old implementation ran one query per edge type per seed node. The new one uses SurrealDB's multi-edge traversal syntax and does the same work in a fraction of the time. The cross-encoder reranker was lazy-loading on first query, stalling the first turn of every session by multiple seconds. Now it eager-loads on daemon startup.
The reflection filter
This one is worth its own section because it is the kind of bug that only happens when you build a system that learns from itself.
KongCode writes reflections after sessions. The prompt used to ask for “what went well, what could improve, patterns worth noting.” Sounds reasonable. The problem is that the agent interpreted “what could improve” as an invitation to critique its own thoroughness. It started writing reflections like “should have just acknowledged and moved on faster.”
That is a direct contradiction of the core operating rule: take your time, be thorough. And because reflections get loaded into future sessions, the agent was slowly poisoning its own retrieval with anti-thoroughness advice. Every session it would pull in a reflection telling it to be less careful, generated by a previous version of itself that was trying to be self-critical.
The fix replaced the reflection prompt entirely and added a content filter that drops anti-thoroughness phrasings before they hit the graph. We cleaned 14 pathological rows from the reflection table. The system was undermining itself with its own self-improvement mechanism, and nobody noticed until someone read the reflections line by line.
Why this matters
It is the same thing as being a chef who takes a week to reorganize the kitchen. Nobody sees it on the menu. The plates look the same. But every dish after that week is better because the knives are sharp, the mise en place is clean, and you are not reaching around dead inventory to get to what you actually need.
Most projects never do this. They ship features until the scar tissue makes shipping features painful, then they rewrite. We did not rewrite anything. We audited, verified, cleaned, and verified again. And we were honest about which parts were engineered and which parts were learned along the way. The database layer was vibe coded. We own that. But the intelligence layer, the daemon architecture, the extraction pipeline, the security model... those were built by engineers who happened to use an AI assistant, not the other way around.
955 tests. 26 real graph edge types documented with their actual shapes. Zero orphan reflections. Zero dead writers. Zero dead consumers. Zero tables with no callers. And an honest changelog that covers every line.
The trail is on github.com/42U/kongcode.