From 7cc18fcb3a85eca57579b172e5beaf7a193c74ab Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Thu, 17 Sep 2026 00:21:47 +0200 Subject: [PATCH] Keep the prior-art facts where they can be reread An Eyes pass established what already exists for a typed query surface, inside the substrate first and in published work second, with an evidence pointer for every claim. It found no reusable shape in our own runtimes, three flat option structs invented independently because no general one exists, and a citation hop query we built and deleted with its host surface rather than on its merits. It lands in the repository because a facts file that lives only in a scratchpad is the same failure as a harness that lives only in a scratchpad, which this campaign has now paid for twice. Co-Authored-By: Claude Fable 5.1 --- notes/eureka-query-prior-art.md | 523 ++++++++++++++++++++++++++++++++ 1 file changed, 523 insertions(+) create mode 100644 notes/eureka-query-prior-art.md diff --git a/notes/eureka-query-prior-art.md b/notes/eureka-query-prior-art.md new file mode 100644 index 00000000..0650028b --- /dev/null +++ b/notes/eureka-query-prior-art.md @@ -0,0 +1,523 @@ +# Prior art for a typed, serializable query surface over a memory organ's read side + +Eyes pass, 2026-09-16/17. Facts with evidence pointers. No ranking, no recommendation. + +## The thing being measured against + +The five capabilities, abbreviated throughout as **C1..C5**: + +- **C1** typed predicates over each kind's own fields, expressed as data +- **C2** projection (summary or whole document) +- **C3** ordering plus an opaque cursor +- **C4** one hop of citation in both directions +- **C5** count / existence without bodies + +The portability facts, abbreviated **P1..P5**: + +- **P1** does the query itself serialize as typed data across runtimes (MessagePack wire, constructible from TS/C#), or is it Rust-only builder calls? +- **P2** does it derive a JSON Schema, or is the schema hand-written? +- **P3** transitive dependency cost; anything dragging in a runtime, network client, DB driver or parser generator +- **P4** does it assume a backing store engine? +- **P5** licence, last release, maintenance signal, single-maintainer? + +## The crate this lands in + +`F:\Projects\Huginn\crates\huginn-mind`, manifest at `F:\Projects\Huginn\crates\huginn-mind\Cargo.toml:9-19`. Dependencies exactly as stated in the brief: `anyhow`, `chrono 0.4.44`, `cultcache-rs` (CultLib, rev `a0813c6e`), `epiphany-pipeline` (Epiphany, rev `5cda0886`), `rmp-serde 1`, `schemars 1`, `serde 1`, `sha2 0.10`. Dev-only: `serde_json`, `tempfile`. The manifest comment states the constraint in its own words: "No network, no socket, no index: those are the daemon's (Cut 10, Cut 11)." + +**The baseline P3 measurement, taken directly.** `F:\Projects\Huginn\Cargo.lock` currently resolves **139 packages** for the whole three-crate workspace. A grep of the lockfile for `tokio`, `hyper`, `reqwest`, `tonic`, `async-std`, `mio`, `prost`, `pest`, `lalrpop` and `nom` returns **NONE** — there is no async runtime, no HTTP client, no gRPC stack and no parser generator anywhere in the tree today. The sibling `huginn-daemon` (`crates/huginn-daemon/Cargo.toml`) gets its socket from `cultnet-rs` and its process lifetime from `signal-hook 0.3`, synchronously. So any candidate pulling a runtime in would be introducing the first one, and the 139 is the number a transitive-dependency count should be read against. + +--- + +# Part I — GameCult-internal candidates + +## I-1. The incumbent: `PipelineQuery` in `huginn-mind` + +**What it is.** A flat option-struct filter, already built, already on the wire, already schema-published. This is the surface a general one would replace. + +**Owner.** `huginn-mind`, this crate. Landed in commit `49cc6e3` "Read a mind: views, queries, open items and history". + +**Evidence.** + +- `F:\Projects\Huginn\crates\huginn-mind\src\query.rs:77-97` — `PipelineQuery`: `campaign: Option`, `repo: Option`, `cut: Option