You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The 1.0 freeze pins the store adapter contract (RawEventStore + WakeSource + AtomicAppend + subscription semantics: GlobalSeq ordering, catch-up→live boundary, conflict detection, batch bounds). Today that contract lives implicitly in nexus-store-testing plus the fjall/postgres test suites — #213 proved it by writing a second adapter by hand.
After freeze, third parties (and bombay M2, and every future backend: sqlite, S3, iroh, whatever) will implement adapters without the tribal knowledge. If the contract isn't executable, every adapter re-discovers the edge cases (the #206 GlobalSeq mismatch, wake-loss races, $all vs per-stream cursor semantics) as production bugs — and "works with nexus" becomes an unverifiable claim.
Proposal
Promote nexus-store-testing into a public conformance kit:
A conformance! entry point (macro or generic fn suite) that takes any RawEventStore + WakeSource [+ AtomicAppend] factory and runs the full behavioral matrix: append/version-conflict, ordering, GlobalSeq monotonicity, subscription catch-up→live→CaughtUp signaling, wake-after-idle, batch-bound respect, snapshot round-trip (feature-gated)
Port the existing fjall + postgres + in-memory suites to consume the kit (they become the proof the kit is sufficient — any behavior they test that the kit doesn't is a kit gap)
The 4 test categories from docs/nexus-store-test-strategy.md (Sequence/Protocol, Lifecycle, Defensive Boundary, Linearizability) become the kit's module structure
Rustdoc page: "writing a store adapter" — contract prose + kit usage, replacing tribal knowledge
Publish it with the workspace (it's the freeze's executable spec)
Why pre-freeze
Writing the kit forces the last contract ambiguities into the open while they're still cheap to fix. It's the same play as cesr's differential-vs-keripy suite: the spec is a test you can run.
Acceptance
A toy third-party adapter (e.g. a HashMap store written against only the rustdoc) passes the kit without reading fjall/postgres source; fjall + postgres + in-memory all run through the kit in CI.
From the 2026-07-05 cross-repo roadmap review (ROADMAP.md Phase 2 prerequisite).
Problem
The 1.0 freeze pins the store adapter contract (
RawEventStore+WakeSource+AtomicAppend+ subscription semantics: GlobalSeq ordering, catch-up→live boundary, conflict detection, batch bounds). Today that contract lives implicitly in nexus-store-testing plus the fjall/postgres test suites — #213 proved it by writing a second adapter by hand.After freeze, third parties (and bombay M2, and every future backend: sqlite, S3, iroh, whatever) will implement adapters without the tribal knowledge. If the contract isn't executable, every adapter re-discovers the edge cases (the #206 GlobalSeq mismatch, wake-loss races, $all vs per-stream cursor semantics) as production bugs — and "works with nexus" becomes an unverifiable claim.
Proposal
Promote nexus-store-testing into a public conformance kit:
conformance!entry point (macro or generic fn suite) that takes anyRawEventStore + WakeSource [+ AtomicAppend]factory and runs the full behavioral matrix: append/version-conflict, ordering, GlobalSeq monotonicity, subscription catch-up→live→CaughtUp signaling, wake-after-idle, batch-bound respect, snapshot round-trip (feature-gated)Why pre-freeze
Writing the kit forces the last contract ambiguities into the open while they're still cheap to fix. It's the same play as cesr's differential-vs-keripy suite: the spec is a test you can run.
Acceptance
A toy third-party adapter (e.g. a HashMap store written against only the rustdoc) passes the kit without reading fjall/postgres source; fjall + postgres + in-memory all run through the kit in CI.
From the 2026-07-05 cross-repo roadmap review (ROADMAP.md Phase 2 prerequisite).