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
{{ message }}
Repository navigation
Commit b21c9ee
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: AGENTS.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,9 +17,10 @@ ManagedCode packages are our projects. Fix dependency defects in their owning si
17
17
- When the user requests committing all current changes, commit the full requested working-tree scope on the currently checked-out branch; do not silently omit existing changes or move them to another branch.
18
18
19
19
## System-critical SMID and operation efficiency
20
-
- Treat the owner's SMID work as a first-priority product workstream and keep it visible in implementation planning and status. The term is not defined in the current repository or v0.3 architecture documents; do not guess its expansion or begin SMID-specific implementation until its canonical slice, REQ/AC criteriaand required ADRs are mapped with the owner.
20
+
- Treat the owner's SIMD work (earlier written as SMID) as a first-priority product workstream and keep it visible in implementation planning and status. On 2026-10-02 the owner confirmed SIMD means vectorized CPU operations and directed .NET intrinsics first, with Rust considered only after profiling. Map its canonical slices, REQ/AC criteria, scalar correctness/portability contract and required ADRs before implementation; never claim acceleration without comparable GitHub measurements.
21
21
- Orleans provides request isolation, cluster routing and activation movement. Keep the one-grain-per-request boundary and RF3 topology; treat Orleans Streams as a first-class architecture workstream to specify and qualify alongside persisted KeyLoad EventStreams. Keep their distinct delivery/restart contracts explicit, and define bounded resource, concurrency, backpressure, recovery and performance behavior for every operation.
22
22
- Optimize each operation only against its correctness and fault contracts, using representative multi-node GitHub qualification to measure latency, throughput, allocations, memory, contention and backlog where applicable. Architecture choices or local builds alone do not prove maximum scalability or performance.
23
+
- Use ZoneTree's native storage APIs correctly and Orleans for bounded parallel execution of independent operation work. Preserve node-local storage ownership, the ordered atomic commit/apply gate, scoped read cuts, cancellation and backpressure; qualify the resulting performance in real multi-node GitHub runs (owner direction 2026-10-02).
Copy file name to clipboardExpand all lines: README.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,9 @@ This is an early implementation of the clustered kernel. The default server topo
14
14
15
15
Implemented surfaces include document CRUD and field patches, partition-scoped unique/composite equality indexes, command deduplication, stream expected-revision append/read, retained topics, per-source durable subscriptions with bounded delivery windows and contiguous checkpoints, scheduled work queues with fenced leases and retry/DLQ, atomic inbox completion, a committed projection outbox with generation pins, protected resumable document changes and scalar live queries, bounded property-graph traversal, ordered samples, exact vector search, BM25 and weighted reciprocal-rank fusion, a bounded read-only Q1 SQL dialect, API keys, field omission and field-use policies, verified backups, native Raft snapshots and empty-replica catch-up, offline journal compaction, a .NET SDK and CLI.
16
16
17
-
The additive [TimeSeries reads](docs/Features/TimeSeries.md) provide latest samples, complete half-open raw aggregates and dense UTC windows through typed SDK, HTTP and MCP operations using published `ManagedCode.TimeSeries` 10.0.0. They preserve the existing inclusive sample range API and persisted authorization. The first complete new-source CI exposed test fixture/catalog/cancellation expectations; their [source corrections](docs/implementation/qualification-source-r9.json) require their own delivered-SHA CI.
17
+
The additive [TimeSeries reads](docs/Features/TimeSeries.md) provide latest samples, complete half-open raw aggregates and dense UTC windows through typed SDK, HTTP and MCP operations using published `ManagedCode.TimeSeries` 10.0.0. They preserve the existing inclusive sample range API and persisted authorization. Their fixture/catalog/cancellation corrections are exercised in [exact c486 CI](docs/implementation/runtime-qualification-37060131271.json): 871/871 unit cases on each OS and 46/46 genuine RF3 SDK/MCP cases pass. Retention, rollups, SQL integration and resource qualification remain open.
18
+
19
+
That complete workflow still fails: Windows recovery is 116/136 and native comparison completion is 2/4; measured profiles were skipped. [The performance diagnosis](docs/implementation/performance-diagnosis-37060131271.json) records missing RF3/Rabbit caller bindings and PostgreSQL stream readback, plus unqualified 48-sample TimeSeries observations. These do not establish a performance winner. The next source stage repairs those callers and adds portable .NET SIMD finite-value validation with unchanged scoring, plus a full unit-suite invocation with intrinsics disabled. Its own delivered-SHA tests and measured benefit are pending; Rust requires profiling evidence first.
18
20
19
21
The [104-task implementation tracker](docs/implementation/status.json) records the remaining work. Automatic canonical journal maintenance, large and interrupted snapshot transfer qualification, shard movement, distributed multi-shard query planning, managed HNSW, subscription coverage discovery across partitions and rebalance, automatic retention and generation cleanup, schema migrations, external backup stores and full release qualification remain under development. The current server uses one replicated physical shard which contains many independent atomic partitions.
0 commit comments