DEV Community: AsiaOstrich

Our graph database was abandoned upstream — here's the 6-line migration (EngramGraph 0.3.0)

AsiaOstrich — Wed, 24 Jun 2026 12:00:26 +0000

In October 2025, Kùzu Inc. archived KuzuDB — the embedded graph database — with a one-line note: "Kuzu is working on something new." The npm package was deprecated, and its transitive dependencies (tar@6.2.1, npmlog, gauge) carried 5 high-severity vulnerabilities with no fix coming.

EngramGraph runs on an embedded graph database. That database was Kuzu.

EngramGraph 0.3.0 is the migration release — and the migration turned out to be far cheaper than expected. Here's why, and what we learned.

The fix: ryugraph

The community responded to KuzuDB's abandonment with several forks. We evaluated them and picked ryugraph (Predictable Labs):

MIT licensed, actively maintained, published on npm
Designed as a drop-in Kuzu replacement — and in our experience, it actually is
Same storage format lineage: existing .engram/graph.db files keep working

The core API — prepare(), execute(), query(), getAll() — is signature-identical to kuzu. Our entire test suite (69 tests) passed on the first run after the swap.

Why the migration was 6 lines

One architectural decision from day one paid for itself here: every raw database call goes through a single thin wrapper (GraphConnection, ~80 lines). The other 20+ call sites in the codebase only ever see the wrapper.

So the migration was:

package.json: kuzu → ryugraph
connection.ts: one import line
Two type-only imports (KuzuValue → RyuValue)

That's it. If your project wraps its native dependencies behind one interface, an upstream abandonment becomes an afternoon, not a quarter.

The leftover CVEs (and the override trick)

Swapping kuzu killed the deprecated-toolchain CVEs, but ryugraph itself pins cmake-js@^7.3.0, whose tar@6.2.1 carries known path-traversal CVEs. The fix exists upstream (cmake-js@8 uses a patched tar) — ryugraph just hasn't bumped yet.

npm overrides to the rescue:

"overrides": { "cmake-js": "^8.0.0" }

npm audit: 5 high → 0.

One caveat worth knowing: npm overrides don't propagate to downstream consumers. If you depend on engramgraph (or anything that depends on ryugraph), add the same override to your own package.json until ryugraph bumps cmake-js upstream.

Upgrading

npm install engramgraph@0.3.0

One breaking change: the KuzuValue type is now RyuValue. If you imported it, update the import — everything else is unchanged.

MIT · Node ≥ 22 · github.com/AsiaOstrich/EngramGraph

Make spec ↔ test ↔ code ↔ doc drift visible: `/sdd analyze` in UDS 5.17.0

AsiaOstrich — Wed, 24 Jun 2026 01:10:29 +0000

Spec-driven development has a quiet failure mode: your specs, tests, .feature files, source, and user docs all start aligned — and then drift apart. A test loses its spec. An acceptance criterion never gets a test. A spec is marked done but was never implemented. Nobody notices until it surfaces in review or production.

Universal Dev Standards (UDS) — a language- and framework-agnostic toolkit of dev standards + AI-native workflows (npm i -g universal-dev-standards) — makes that consistency executable in 5.17.0.

`/sdd analyze` — one command, 7 drift signals

/sdd analyze (XSPEC-262) scans your spec-driven artifacts and reports seven kinds of cross-artifact drift:

Orphan test — a test with no spec behind it
Uncovered AC — an acceptance criterion with no test
not_implemented — a spec marked done but absent in code
Cross-spec conflict — two specs that contradict each other
Orphan .feature — a feature file with no owning spec
AC-without-scenario — an AC that no BDD scenario exercises
user-guide ↔ E2E drift — docs and end-to-end tests out of sync

It's backed by scripts/sdd-analyze.ts with 12 bats tests, and it fulfils XSPEC-260 R5 (extending the test-derivation chain all the way to user docs).

Two smaller additions

EARS notation (XSPEC-263) — EARS is now an optional AC format (ears field in the schema). Given-When-Then remains the preferred default; EARS is there when a requirement reads more naturally as "When , the system shall ".
Structured Bugfix Spec Template (XSPEC-264) — the sdd-guide now splits into a decision tree plus a dedicated template for bugfix specs, so a fix gets the same traceability as a feature.

Adopting it

Everything in 5.17.0 is additive and backward compatible — no migration.

npm i -g universal-dev-standards

If you already run spec-driven development, /sdd analyze is the cheapest way to find out how much your artifacts have quietly drifted.

github.com/AsiaOstrich/universal-dev-standards

A hyped memory paper dropped. We didn't adopt it — and that was the point.

AsiaOstrich — Mon, 15 Jun 2026 12:00:25 +0000

Our daily scout surfaces AI-tooling papers every morning. Most weeks the disciplined answer to a shiny new architecture is "no" — and why you say no is where the engineering judgment lives. Here's one worked example.

In May 2026, SAGE: A Self-Evolving Agentic Graph-Memory Engine (arXiv:2605.12061) made the rounds. The pitch is genuinely good: turn graph memory from a passive retrieval middleware into a dynamic long-term substrate, via two coupled components — a Memory Writer that incrementally builds the graph from interaction history, and a Memory Reader that retrieves and feeds back to the writer. That reader→writer feedback loop is the self-evolution engine. The paper reports strong multi-hop QA results, best after two self-evolution rounds.

The reflex that paper triggers in most teams: new SOTA memory architecture — let's rebuild on it.

We did the opposite. We opened our own design doc first.

We already had it

EngramGraph (our open-source code + knowledge-graph memory engine) already specifies a SAGE Evolution Loop:

a Writer that updates node confidence in the graph from feedback events — test pass/fail, human corrections, spec-status changes;
a Reader that returns high-confidence nodes first on query, and feeds that signal back to the Writer.

Line that up against the paper:

SAGE paper	EngramGraph (existing design)
Memory Writer, incremental build	Writer: feedback event → update node confidence / edges
Memory Reader, retrieve + feed back	Reader: high-confidence-first → feeds back to Writer
Downstream feedback drives evolution	Signals: test pass/fail, human fix, spec-status change

Architecturally isomorphic. Adopting the paper's architecture wholesale would have added roughly nothing — except a rewrite, a migration, and the risk that comes with both.

So we borrowed the rigor, not the architecture

A paper that matches your design is still valuable — just not as a blueprint. It's valuable as backing and method. We extracted exactly the three things our design was actually missing:

Formalization — academic grounding for why a reader-writer feedback loop beats static-graph retrieval. Useful when you have to defend a design, not just ship it.
A validation method — the paper's benchmark thinking inspired a code-graph memory-quality yardstick, which moves our loop from "designed" to "measurably verified." This is the real prize: a way to prove the thing works, not just assert it.
Iteration-rounds design — the paper's "best after two self-evolution rounds" gave us a convergence-rounds definition our loop simply didn't have.

The honest caveat (this is the part that matters)

Here's the line we drew, in writing, before borrowing anything:

The paper's benchmarks are multi-hop QA, Natural Questions, LongMemEval, HaluMem — none of which is a code-graph scenario. The absolute numbers do not transfer.

So we explicitly refuse to port the paper's numbers into our domain. Every threshold in our borrow record is a relative comparison — confidence-weighted reader vs. our own static-MERGE baseline — not "the paper got 91.6, so we should too." Cargo-culting a benchmark from dialogue memory into a code graph is exactly how you manufacture fiction and call it a result.

We also wrote down what we deliberately did not take: the paper's agent-dialogue-memory scenario doesn't fit a code graph, so its scenario-specific mechanics stay on the shelf.

Why log a "no" at all

Because a tech radar isn't a list of things you adopted. It's a record of judgment. We filed SAGE as Trial, scoped to relative validation, with the non-adoptions named. Six months from now, that record tells us — and anyone reading — not just what we believed, but how carefully we believed it.

Half of staying current is reading everything. The other half is the discipline to take only the part that's actually load-bearing for your problem.

The decision record (DEC-078) and the design (XSPEC-237) are part of how we work in the open. EngramGraph itself is MIT, Node ≥ 22, no LLM required.

→ github.com/AsiaOstrich/EngramGraph

Introducing UDS — one playbook of dev standards your AI assistant actually follows

AsiaOstrich — Tue, 09 Jun 2026 13:23:16 +0000

Every team has "standards" — a wiki page nobody reads, a linter config, tribal knowledge. The moment you switch stacks, start a new repo, or hand work to an AI assistant, consistency resets to zero.

Universal Dev Standards (UDS) is an attempt to fix that: a language- and framework-agnostic set of development standards plus AI-native workflows, installable in one command.

What it is

50+ standards (commits, testing, ADRs, security, API design, …) written to be language- and framework-agnostic.
50+ skills / slash commands that turn those standards into actions: /discover, /sdd (spec-driven dev), /reverse (legacy code), /commit, /tdd, /security, and more.
AI-native: it's built to drive AI coding tools (like Claude Code), so your assistant follows the same reviewable standards you would.

Try it

npm i -g universal-dev-standards
cd your-project
uds init

uds init wires the standards into your AI tool's config. Then, in your editor:

/discover to understand an unfamiliar codebase
/sdd to build a feature from specs
/commit for a clean, conventional commit

MIT + CC BY 4.0, open source. Repo and docs: github.com/AsiaOstrich/universal-dev-standards

Feedback welcome — especially what standards or workflows you'd want next.