v1.1.0 ·
The framework that forgot everything: a local knowledge graph
Every time AIDLC needed to understand your code, it started from zero. It re-read directories, re-inferred the architecture, re-discovered the conventions and the debt. And when it changed the code, whatever it had learned was gone at the end of the session.
The framework had no memory of the codebase it worked on. This release gives it one.
What changed
The local knowledge graph is a read and write memory kept in your repo as YAML. Before a phase acts on code, it queries the graph instead of exploring. After a phase changes code, it updates the graph straight away: new or changed modules, decisions taken, debt added or paid down. The aim is a memory that stays current as the work runs, not a snapshot taken once at discovery.
I checked it the way a user would. In a scratch project, npx @rasensio/aidlc@latest discover wrote the context docs and seeded the graph with 5 entities, and knowledge query returned matches from the freshly published package.
Why this storage
The shape was settled early: YAML as the source of truth, with a derived index for queries. The open question was what the index lives in, and every candidate had a real cost.
better-sqlite3 gives the fastest queries and full-text search, but it would be the first native dependency in the CLI. That means prebuilt-binary and build failures on some platforms and a CI matrix across three operating systems and several Node versions. An in-memory index needs no new dependency and fits a 100ms query budget at about a thousand entities, but it re-parses YAML on every run and its relevance ranking would be cruder. node:sqlite from the standard library gives real SQLite and full-text search with no native build.
I chose node:sqlite. The price is that the CLI now needs Node 22.13 or newer, up from 18. That breaks existing users on older Node, so it needed a major-version signal and a callout in the release notes. The writer, the reader and the context generator all sit behind a narrow index interface, so if the trade ever looks wrong the engine can be swapped.
What went wrong on the way out
The release is v1.1.0, not v1.0.0. I drove one release-script step by hand while re-authenticating, and the version counter ended up one step further than planned. A 1.0.0 bump commit exists in history, but 1.0.0 was never published, so I accepted 1.1.0 rather than re-tag. The first publish also failed on an expired npm token. Nothing was partly published, and it went through after I logged in again.
The generated release notes were a bare changelog link with no mention of the Node requirement, so I edited them to add it.
One bug turned up that this release did not cause and does not fix. aidlc --version reports 0.1.0, because packages/cli/src/cli.ts hardcodes it. It has been wrong in every published version.