Thin reference bindings for graph-lite, one per runtime, living outside the library: they exist to prove the C ABI is usable from outside, which is the only honest test of a C surface designed by C++ programmers.
Done when
- Ruby (FFI), JavaScript (
bun:ffi and/or N-API), Python (cffi) each: open a store, add nodes and edges, traverse, read properties, handle a status code, close.
- Each binding is one file and needs no C compilation step beyond the shared library — if it needs a wrapper
.c, the ABI is wrong, and that finding is the point of this issue.
- Every friction point found is filed against the C surface rather than papered over in the binding.
- Ownership rules are exercised: a buffer that is too small, a handle used after close, a code the binding does not recognise.
Notes
Not shipped as supported packages at this stage — reference quality, in-repo, to keep the feedback loop honest.
A binding in the engine's plugin language would currently trip scripts/lint/graph-lite-vocabulary.ts, which bans that language's name as a consumer dependency. If that binding becomes wanted, revisit the ban deliberately — do not add an allowlist entry.
Thin reference bindings for graph-lite, one per runtime, living outside the library: they exist to prove the C ABI is usable from outside, which is the only honest test of a C surface designed by C++ programmers.
Done when
bun:ffiand/or N-API), Python (cffi) each: open a store, add nodes and edges, traverse, read properties, handle a status code, close..c, the ABI is wrong, and that finding is the point of this issue.Notes
Not shipped as supported packages at this stage — reference quality, in-repo, to keep the feedback loop honest.
A binding in the engine's plugin language would currently trip
scripts/lint/graph-lite-vocabulary.ts, which bans that language's name as a consumer dependency. If that binding becomes wanted, revisit the ban deliberately — do not add an allowlist entry.