shacl-runner: swap to shacl-engine so SHACL-SPARQL shapes actually run (#58)

[bdelanghe]

Completes #58. One engine, and the reproducible artifact built and exercised in CI.

What it fixes

rdf-validate-shacl cannot execute SPARQL-based constraints at any version in range:

rdf-validate-shacl@0.5.10 (the pin)  → Error: Cannot find validator for constraint
rdf-validate-shacl@0.6.5  (latest)   →   component sh#SPARQLConstraintComponent

Core SHACL cannot traverse a property path, so every cross-row invariant — referential agreement, acyclicity, "this status implies that relationship" — requires sh:sparql. The gate could enforce per-node structure and nothing relational, and announced that by throwing in a way that reads like an infrastructure fault rather than an unsupported feature.

shacl-engine is the same RDF/JS stack — same @zazuko/env-node the kit already depends on — and implements SHACL-SPARQL constraints and targets. Report format and exit codes are unchanged; printViolations normalises the two engines' differing result shapes (path as segments vs a single term, constraintComponent vs sourceConstraintComponent) so consumers reading these logs see no difference.

⚠️ The hazard, and the guardrail

shacl-engine ships core validations only. Without targetResolvers and validations from shacl-engine/sparql.js, it does not warn and does not throw — it silently skips every sh:sparql shape:

default config          → conforms: TRUE     ← the cycle is invisible
with the sparql opt-in  → conforms: false, cycle reported

That is a worse failure mode than the validator it replaces, which at least threw loudly. So the swap lands with a required-to-fail cyclic fixture — and I verified that guard actually guards, by removing the opt-in and watching what happened:

✓ gates/shacl-runner: sh:sparql shapes + conforming data → conforms:true   ← STILL PASSES
✗ gates/shacl-runner: sh:sparql violation → exit 1 (opt-in wired)          ← catches it

The conforming test still passed with SPARQL disabled. Only the negative test caught it — which is the entire argument for having one.

On the dependency footprint

shacl-engine hard-depends on @comunica/query-sparql-rdfjs-lite, so the Comunica query engine comes with it: 297 → 758 lockfile packages. It is not a peer or optional dependency, so there is no way to take shacl-engine's core validations without it.

I originally raised this as a blocking question and leaned toward keeping both engines with a dynamic import. That was the wrong call, for two measured reasons:

• Determinism here is a property of the artifact, not of the dependency count. The kit ships its gates as Nix CLIs and npmDepsHash content-addresses the entire tree, so a consuming site's vendored gate is hash-verified rather than re-resolved at install.
• The added packages carry no new known vulnerabilities. OSV reports exactly the same 7 advisories (fast-uri, ip-address, undici) as main — all pre-existing, none from Comunica.

And two engines would have meant two code paths, two result shapes, and two answers to "what does this gate enforce?" One engine is the point.

The reproducible path had stopped being built

Following from that, the flake had to actually work — and it didn't. flake.nix declares all 29 ck-* gates as reproducible CLIs, but:

• nothing in CI ever built it
• flake.nix said 0.8.0 while package.json said 0.11.0 — three minors of drift
• npmDepsHash had never been checked against the lockfile it claims to pin, so this PR's lockfile change made it detectably wrong rather than newly wrong

A reproducible-build guarantee nobody executes decays in exactly one direction. The new flake job runs nix build (which fails loudly on a stale hash and prints the correct one — that is how the pinned value here was obtained), asserts version agreement, and then runs the built binary:

built CLI: conforming passes, cyclic is rejected

Building is not evidence the artifact works. That line is the Nix-built ck-shacl-runner validating a conforming graph and refusing a cyclic one through a SHACL-SPARQL property path — so the binary a consumer vendors is verified, not just the source tree.

Verification

✓ sample shapes + HTML → conforms:true          (existing, unchanged)
✓ --turtle dataset → conforms:true              (from #59)
✓ violating dataset → exit 1, violations named  (from #59)
✓ --turtle with no path → usage error           (from #59)
✓ sh:sparql shapes + conforming data → conforms:true   ← proves it RUNS, not just fails
✓ sh:sparql violation → exit 1 (opt-in wired)          ← required-to-fail

32 passed. build green. version-check green.

Known-red, and deliberately not fixed here

osv / osv-scan fails on 7 advisories in fast-uri, ip-address and undici. All are pre-existing — present in main's lockfile, and this branch's additions contribute none of them. They are real and fixable, but a three-package lockfile bump inside an engine swap would make one diff about two unrelated things. Worth its own PR.

Also unexplained and worth someone's attention: standard / osv passes the same lockfile that osv / osv-scan fails. Two scanners disagreeing about one input is worth understanding regardless of which is right.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MqhgW5RCRn6wWfjKvDsxTq