Author	SHA1	Message	Date
Libby	7760219b7c	CultCache: [CultIndex] is unique at commit and load; [CultRole] names a selection role; replicas apply a commit's changes as one batch (#90)	2026-11-11 03:48:08 +00:00
Meta Vens	a4cf54f4a9	Land fix batch 3's R-O and R-Q: keyed length-prefixed cursors, replica-apply sequence gap ... R-O: CultNetSelectionCursorKey is a per-process (per-CultNetDatabase-instance) 32-byte random key. CultNetSelectionCursor.ComputeDigest is now an HMAC-SHA256 under that key instead of an unkeyed SHA-256, so a cursor cannot be forged without the key and does not verify across a restart (a fresh CultNetDatabase mints a fresh key). The cursor body (asOf/ordinal/schemaId/recordKey/digest) is length-prefixed (<byte length>:<value>, no delimiter) instead of joined with a bare "\x01"-separated string, so a record key carrying any character, U+241F included, round-trips. CultNetSelectionEvaluator.Select/ Page/ComputeDigest take an optional CultNetSelectionCursorKey, defaulting to a process-wide key generated once so existing callers that never wire up a database still get a keyed digest. CultNetDatabase gets a CursorKey property (random unless CultNetDatabaseOptions.CursorKey is supplied) and passes it through CultNetDatabaseServer.CreateSelectionResponse. Rust already landed R-O (5aac120) under its own algorithm, deliberately not byte-matching the reference: its own doc comment says a cursor is never handed across runtimes, so only collision-freedom and keying are load-bearing, not the wire bytes. That is a real divergence from this pass's instruction to match Rust's wire encoding exactly - reported in full in the batch report. R-Q: the two replica-apply paths (ApplyCommittedPutAsync, ApplyCommittedDelete) recorded the mutation-log entry but never set _lastWriteSequence, so a row's order/cursor position looked like "never written" until it was written again locally. Both now set it from the entry's own sequence, matching AppendMutationLogEntry's local-commit path. InitializeLogSequencesFromStore rebuilt only _nextLogSequences at startup; it now also rebuilds _lastWriteSequence by replaying the durable log's Put/Delete entries in sequence order. CultNetDatabase.ResolveShard is a new public wrapper over the existing shard resolution; CultNetDocumentRegistry.SelectPage/CreateSelectionResponse take an optional shardIdOf callback and refuse (reusing CultNetSelectionInvalidException/selection_invalid, R-N) when a selection's matched rows resolve to more than one shard's log, because asOf is a single watermark and is not exact for a shard-spanning page. CultNetDatabaseServer.CreateSelectionResponse wires shardIdOf/cursorKey through from the database. Also fixes a defect the Rust Hands found while matching wire bytes: CultNetErrorMessage.ForReferenceOutsideTarget double-prefixed "reference_outside_target: " - the exception's own message already carries it. Now prefixed once, matching Rust's ForReferenceOutsideTarget. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 20:04:22 +02:00
Meta Vens	e8a3decbab	Fix batch 3 tests: R-N wire decode, R-P wire-id authorization, R-T removal/cites ... Four CultNetErrorMessage wire round-trip tests (decode the bytes a peer actually receives) proving code+details for selection_invalid, cursor_stale, cursor_invalid, reference_outside_target. A subscription-server round trip proving snapshot and first live change are authorized by the same wire id (R-P). A subscription-server round trip proving a removal under a field-predicate selection is delivered with no exception (R-T(a)). An evaluator test proving an implicitly-typed many reference still refuses an out-of-target edge (R-T(b)). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 19:46:32 +02:00
Meta Vens	e5348d3d57	CultNet selection cut1, commit 2f: the Q-J fix (canonical decimal numbers) ... Corrects commit 1's Number field: docs/cultnet-selection-cut.md section 2 "Numbers" (added 2026-09-22, superseding the map's own stale float64 text) specifies canonical decimal strings per the operator's Q-J ruling, and commits 0/1 shipped double instead - the Rust Hands caught the conflict before writing a line and stopped; this is the correction the map's Progress block calls for before Rust starts. - CultNetFieldPredicate.Number: double? -> string?. New CultNetCanonicalNumber (CultNetSelection.cs) is the wire's canonical grammar and comparator: IsCanonical validates ^-?(0|[1-9][0-9]*)(\.[0-9]*[1-9])?$ and excludes "-0" (the regex alone matches it); Compare orders by sign, then the integer part's length, then its digits, then the fraction padded on the right to equal length - a pure string function, no double anywhere on the path. ValidateField refuses a non-canonical number at the door (selection_invalid) rather than normalising it. - CultNetSelectionEvaluator.CompareNumber now takes two canonical strings and switches on CultNetCanonicalNumber.Compare's sign instead of comparing doubles directly. - CultCache.cs: CultDocumentDescriptor.TryGetIndexNumber and PersistedMember.NumberOf render a member's exact canonical decimal instead of a double. An integer renders exact (no 2^53 limit); decimal strips trailing fractional zeros; float/double use .NET's shortest round-trip ToString(), rewritten out of exponent notation to positional digits (ExpandScientificNotation) before the shared CanonicalizeDecimalDigits strips zeros and collapses a negative-zero result to "0"; NaN and infinity render null (TryGetIndexNumber returns false, matching "matches no comparison"). - contracts/cultnet/cultnet.selection.schema.json: "number" is now a string with the canonical pattern (a defence-in-depth (?!-0$) lookahead beyond what the door enforces in code), not a JSON number. - Tests: CultNetCanonicalNumberTests (new) pins IsCanonical/Compare directly, including the door's five named non-canonical spellings, magnitude vs. lexicographic ordering, sign, integer-part length, and a long past 2^53 against its float64 rounding. CultNetSelectionEvaluatorTests gains ValidationRefusesNonCanonicalNumberSpellings (+1, 1.0, 01, 1e3, -0) and its existing Number literals become canonical strings. CultDocumentSelectionSurfaceTests gains a dedicated FixtureLeafNumbers fixture and four tests: the 2^53+1 long rendering exactly, a decimal's trailing zeros stripped, a double's exponent notation rewritten to positional digits (1e21, 1e-7), and NaN/Infinity answering false. Mutation entries (scripts/mutate-dotnet.ps1): four new Caching entries (integer-through-float64, decimal trailing zeros, exponent expansion, NaN/Infinity) and five new Networking entries (the door's regex, the door's explicit "-0" exclusion, the comparator's integer-length check, a lexicographic-whole-string mutant, and the comparator's sign check) - all KILLED. The two pre-existing S16 (le/ge boundary) entries had to be re-anchored: their Old text quoted CompareNumber's previous double-based `left <= right`/`left >= right` spelling, which no longer exists now that CompareNumber switches on Compare's int result: `cmp <= 0`/`cmp >= 0`. Verification: dotnet test - GameCult.Networking.Tests 192/192 (was 183 before these additions), GameCult.Caching.Tests 192/192 (was 188), GameCult.Mesh.Tests 252/253 (one pre-existing unrelated skip, unaffected by this commit - no Mesh source touched). Caching mutation run: 10/10 KILLED (6 pre-existing + 4 new), M0 and final both green. Networking mutation run: 15/15 KILLED (10 pre-existing + 5 new, across CultNetSelectionEvaluator.cs, CultNetDatabase.cs and CultNetSelection.cs), M0 and final both green. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 04:18:22 +02:00
Meta Vens	17d10e017f	CultNet selection cut1, commit 1: the shape, the evaluator, v1 messages ... docs/cultnet-selection-cut.md section 2/4/6/7/8: CultNetSelection (schemas, keys, fields, cites, cited, projection, descending, limit, cursor) with its door validation (S1), and CultNetSelectionEvaluator: the single-row Matches fast path (D6) and the full Select (order, hop, cursor, paging). Neither reflects over a document; both read only through the cache's public surface (commit 0). Three v1 messages beside v0 (cultnet.snapshot_request.v1, cultnet.database_subscribe.v1, cultnet.snapshot_response_raw.v1), their schema files under contracts/cultnet, registry entries and dispatch arms. CultNetSchemaAliasMatching goes internal -> public (D4), the one alias matcher. CultNetDatabase gains LastWriteSequence(schemaId, key), confirmed at the one append site (AppendMutationLogEntry) that every committed write takes a shard-log sequence, including a local PutAsync outside any shard. Three engines deleted, one evaluator wired in their place: - CultNetDocumentRegistry: CreateRawSnapshotResponse's reflection loop over cache.AllEntries and MatchesRequestedSchema gone; cache.AllStoredDocuments replaces the reflection entirely. v0 lowers into a Selection and walks the evaluator's own pages so a v0 caller still sees its whole matching set (D3: v0 has no engine of its own). CreateSelectionResponse/SelectPage/ ToRawRecord/CreateSnapshotRequestV1 added. - CultNetDatabaseServer: CreateChangeMessage/CreateRawDocumentRecord/Matches/ MatchesSchema/InferSchemaName (122 lines) deleted; CreateSubscription lowers v0 into a Selection and matches through the evaluator. - CultNetDatabaseSubscriptionServer: CreateAuthorizedChange/CreateChange/ CreateChangeCore/ResolveWireSchemaId/MatchesRequestedSchema/CreateRawRecord (92 lines) deleted, replaced by CreateMatchedRecord. _projectRecord and CreateProjectedSnapshot's collapse are commit 2's, per the map's own deletion line, and are untouched here. Discrepancy found and fixed (not in the map): CultNetDocumentBinding can carry a schema id different from its descriptor's own (CultNetDocumentBinding.ForDocument's schemaId override), which the old per-engine matchers checked and a descriptor-only evaluator cannot see by design (it stays decoupled from CultNetDocumentRegistry). Fixed at the two call sites and in CultNetDocumentRegistry.SelectPage by resolving the binding's schema id into the effective selection before evaluation (CultNetSchemaAliasMatching.WithBindingSchemaAlias, CultNetDocumentRegistry.ExpandSchemaBindingAliases), not in the evaluator. Found by DatabaseSubscription_FiltersLiveChangesByWireSchemaBinding timing out; both call sites now pass. Second discrepancy, reported not fixed: CultNetDatabase.cs:1707 has a fourth, undocumented copy of schema-matching logic (MatchesRequestedSchema, private, serving CreateShardSnapshotResponse), which the map's section 1 audit did not name among "three separate selector engines". Left untouched this commit: it is out of the map's explicit deletes list and touching it risks shard snapshot behavior with no budgeted verification. Verification: dotnet test tests/GameCult.Networking.Tests - 162 passed (150 existing + 12 new), 0 failed; the seven map-named tests all still pass, two rewritten for the new signatures (CreateChangeMessage now takes CultNetSelection; CreateChange/CreateAuthorizedChange collapsed into CreateMatchedRecord, returning CultNetRawDocumentRecord? directly). tests/GameCult.Mesh.Tests - 252 passed, 1 pre-existing skip, 0 failed (no Mesh source touched this commit). tests/GameCult.Caching.Tests - unaffected (188, unchanged from commit 0). Negative greps: GetProperty|GetField|GetCustomAttribute in GameCult.Networking - only against the generic `object change` dispatch (CultNetDatabaseChange<T>) and CultRecordHandle<T> construction, pre-existing and out of this cut's scope, never against a document's declared values. _projectRecord survives in CultNetDatabaseSubscriptionServer.cs (expected, commit 2). CultNetSchemaAliasMatching is the only schema matcher outside the one reported discrepancy. scripts/mutate-dotnet.ps1: the caching mutation runner generalized into a shared dotnet/NUnit harness (Target/TestProject/Entries/ControlFilter), replacing scripts/mutate-cultnet-selection-caching.ps1 with an entries file of the same six mutations (re-verified: all six still KILL). It is now generic to any NUnit project in this repo, not only this campaign's two targets - a candidate to sit beside tools/eureka-mutations.ps1 as the dotnet-side counterpart. Nine new networking entries (S3, S5 x2, S7 x2, S16 x2, S18) all KILLED. Not yet mutation-run: S1, S2, S6, S23 (pinned by tests, not by a committed mutant); S9-S15 (subscription reconcile lowering, v0 no-engine-of-its-own); S17, S20 (pinned by tests only). S19/S21/S22 are cache-layer, covered in commit 0. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 02:31:42 +02:00