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 ffab3ee
Browse filesBrowse the repository at this point in the historyBrowse files
Strengthen native operation flows and SIMD qualification
Expand complete authorization, replay, ANN, graph, queue, blob, time-series and replica integrity flows; keep native source/image admission and SIMD-only qualification consistent. Commit the complete current working-tree scope on main.
Validation: full Release build with 0 warnings/errors; current changed-file SDK formatting passed; fresh 3383 Unit and 394 Integration discovery plus strict Unit inventory/PE/PDB/source binding passed; all 22 related whole-operation cases passed without skips or source/image/entry drift. Native pool50, observed overlap16.
Linux, full functional coverage, public RF3 and complete task gates remain mandatory. Original failed runs are retained separately. The final native Roslynk diagnostics request failed with an incomplete HTTP reply; no clean native diagnostic result is claimed.
- SIMD is always enabled in the product. This explicit correction supersedes active `unit-scalar`, disabled-intrinsics and normal/scalar matrix requirements above. Execute every ordinary unit, process-recovery, RF3, coverage and benchmark contract through its normal native SIMD image; retain actual original historical reports without relabelling or reusing them as current qualification.
6
+
- Preserve the complete functional case inventory, native TUnit50, five confined coverage groups, 80/70/90 thresholds, source/PE/PDB/TRX provenance, real Aspire topology, authentication and cleanup. Performance comparisons use matched competitor workloads and original previous-code measurements, never a current product SIMD-disable switch.
7
+
3
8
## Build and Tests scope, owner correction 2026-10-06
4
9
5
10
- Build and Tests executes only solution builds, repository checks and KeyLoad functional tests. Benchmark/comparison cases and their progress, entry, counter and image-preparation checks belong exclusively to Benchmarks. Keep benchmark contracts in KeyLoad.ComparisonTests, not KeyLoad.UnitTests; retain their assertions and execution in Benchmarks. RF3 functional qualification builds only the KeyLoad server image, never a benchmark load-generator image. This explicit owner correction supersedes earlier benchmark-correctness placement in ordinary CI.
Copy file name to clipboardExpand all lines: AGENTS.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,6 +29,7 @@ ManagedCode packages are our projects. Fix dependency defects in their owning si
29
29
- The owner clarified on 2026-10-03 that the core product is one composable database for AI agents: documents, typed tables, graphs, blobs, queues, events, vectors/search and time series coexist and reference one another within one database. Logical tables, collections and queues MUST NOT become isolated model silos. One authorized bounded SQL request MUST be able to read queue messages, resolve their referenced entities and write derived knowledge-graph relationships, and perform the reverse graph-to-queue flow, with explicit same-partition atomicity, authorization, read-cut, retry and cross-partition contracts. SQL is the familiar shared language for this composition. Keep this purpose explicit in ADRs, feature requirements, architecture, README and website, while distinguishing delivered syntax and qualification from the complete product target.
30
30
- Treat relational integrity and unified SQL as first-class product workstreams alongside SIMD and operation efficiency. Specify typed rows, keys/constraints, joins, atomic boundaries, unsupported diagnostics and measured performance before advertising capability; preserve RF3 and node-local storage ownership. A unified database/file delivery requirement MUST NOT be interpreted as permission to discard replication journals or promise a single physical file without a qualified storage-format ADR.
31
31
- 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.
32
+
- Owner correction 2026-10-11 makes SIMD-enabled execution mandatory in the normal product and qualification path. Use the native .NET vector/intrinsics implementation appropriate to the supported CPU; remove product SIMD disable switches and active forced-no-SIMD execution, qualification and benchmark profiles. Scalar arithmetic may remain only where required for bounded vector tails or an independent correctness oracle, not as an optional product execution mode. Validate required hardware support explicitly rather than silently selecting a full scalar implementation. This rule-specific direction supersedes the earlier scalar portability/disabled-intrinsics profile requirements; preserve their immutable historical receipts without admitting them into current qualification. Measure performance against genuine equivalent competitor workloads and original previous-code benchmarks, with matched source, hardware, topology, resource and durability contracts; no speed claim follows from code review alone.
32
33
- 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.
33
34
- Owner direction 2026-10-05 requires evaluating and using native Orleans execution/scheduling primitives where their guarantees fit: bounded `[StatelessWorker]` pools for interchangeable independent work, `[OneWay]` only for loss-tolerant advisory signals, durable jobs for persisted at-least-once scheduled work with idempotent effects, and selective `[Reentrant]`, `[AlwaysInterleave]`, `[MayInterleave]` or `[ReadOnly]` scheduling after an await/state-invariant audit. Freeze per-grain/method choices, limits, provider/version maturity, identity isolation and restart/failover contracts in ClusterRouting requirements and an ADR before integration; qualify correctness and resource/performance behavior through Aspire RF3. Preserve the unique request grain, persisted authorization, scoped read cuts, ordered node-local commit/apply ownership and RF3 acknowledgement barriers; these primitives MUST NOT become blanket concurrency attributes or substitutes for durable receipts.
34
35
- Owner clarification 2026-10-05 explicitly includes Orleans Grain Services, silo-local DI services and startup/lifecycle facilities alongside Durable Jobs in native capability selection. Choose them by actual per-activation, per-silo, cluster-partitioned or durable-work ownership; freeze startup dependencies, readiness, admission, cancellation and joined shutdown before integration. A service registered on every silo MUST NOT be treated as a cluster singleton or a durable job queue; retain node-local storage ownership and route every database effect through its separately authorized request grain.
@@ -194,6 +195,8 @@ The explicit owner instruction to enable Orleans distributed directory and activ
194
195
### Continuous Quality Review (owner direction 2026-10-06)
195
196
196
197
- Quality review is a mandatory development loop for every code change. Establish the relevant baseline before non-trivial implementation, review each completed implementation stage, and finish the review before committing that stage or declaring the task complete. Apply this rule to changed code and affected shared execution paths so quality improves throughout development.
198
+
- Owner correction 2026-10-11 requires complete feature batches: each available worker continuously owns a distinct direction, reviews its full affected code and operation contracts, fixes the related findings together, and supplies one coherent reviewable implementation. The integration owner combines ready batches before the final build, native analysis, formatter and relevant whole-operation TUnit execution with the configured parallelism50. Do not repeat unchanged suites, rebuild after each individual finding, or turn small checkpoints into the delivery strategy. Rerun checks only for changed inputs, an actual failure or an unresolved acceptance condition; preserve every required final suite, actual failure and exact-source delivery gate. This direction changes batching and development workflow, not correctness, authorization, durability, test quality, evidence or completion requirements.
199
+
- That explicit 2026-10-11 batching direction supersedes the earlier Ralph Loop instructions to execute one implementation step at a time, reproduce/fix findings one by one and repeatedly build/test between those findings. Preserve the complete requirements, review, operation tests and final qualification contract while resolving related findings together in each complete batch.
197
200
- Read the installed `SKILL.md` instructions and review all ten skills sequentially: `quality-ci` → `analyzer-config` → `format` → `csharpier` → `code-analysis` → `roslynator` → `meziantou-analyzer` → `stylecop-analyzers` → `complexity` → `crap-score`. Each applicable skill MUST produce an actual check, finding or improvement; record a concrete reason when a skill or tool is N/A. A checklist alone is not verification.
198
201
- Preserve the repository's selected tools and `.editorconfig`. `dotnet format` remains the canonical formatter; CSharpier execution is N/A while that choice remains in force. Review third-party analyzer findings against repository contracts; skill use does not automatically authorize adding analyzer packages, applying conflicting defaults, suppressing diagnostics, reducing severity or weakening existing limits and gates.
199
202
- Report every confirmed actionable finding with its source location, severity, consequence and verification status. Keep advisory diagnostics distinct from confirmed defects. Fix confirmed problems within the authorized scope, add meaningful regressions where behaviour is affected, and rerun the affected checks after each fix. ManagedCode dependency defects MUST follow the owning-repository repair, release and verified-publication policy.
Copy file name to clipboardExpand all lines: docs/ADR/ADR-014-principals-rbac-row-policy.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -156,3 +156,7 @@ Node composition remains in the original PartitionHost: the existing canonical D
156
156
## TASK-KL065-GENERATION-ADMISSION-EXTRACTION-003
157
157
158
158
The cache retains its original lock, closed check, scope lookup, invalidation and retirement ownership. Native lease reservation and successful constructor-to-pin transfer are owned by the existing `Admission/RowVisibilityTransfers.CreateLease`; the call occurs under the same cache gate. Direct nullable-reservation disposal and initiating/cleanup error preservation remain unchanged. No new owner, callback, quota, public/persisted contract or policy is introduced. Both original GenerationVisibilityTests whole operations verify cross-tenant/revoke/repair/replay, pinned retirement/admission/cancellation and same-root cold continuation in normal/scalar profiles. Canonical formatting, build and authentic runtime gates remain required.
159
+
160
+
## TASK-KL065-GENERATION-WRITE-VISIBILITY-002
161
+
162
+
The same two GenerationVisibilityTests operations additionally retain the original negative ID set while a real root-authorized row CAS changes its team visibility, retain the subsequent positive set through a real tombstone and resurrection, and verify full independent current SQL/point/native-record values. All three genuine root command receipts and original outcomes replay with no effects before and after same-root cold. Old pinned sets are data only; current positive candidates still pass fresh persisted row policy. Original tenant/epoch/revoke/repair/admission/cancel/retirement assertions, declarations, deadlines, budgets and cold ownership remain unchanged. This test-only continuation changes no public or persisted contract; local evidence is separate from Linux/RF3/resource gates.
0 commit comments