Reduce CI to one build-and-test job

.github/workflows/ci.yml

@@ -10,11 +10,7 @@ permissions:
 
 jobs:
   build-and-test:
-    strategy:
-      fail-fast: false
-      matrix:
-        os: [ubuntu-latest, macos-latest]
-    runs-on: ${{ matrix.os }}
+    runs-on: ubuntu-latest
 
     steps:
       - name: Check out repository
@@ -30,26 +26,3 @@ jobs:
 
       - name: Test
         run: ctest --test-dir build -C Release --output-on-failure
-
-  sanitizers:
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Check out repository
-        uses: actions/checkout@v6
-        with:
-          persist-credentials: false
-
-      - name: Configure sanitizers
-        run: >-
-          cmake -S . -B build-sanitized
-          -DCMAKE_BUILD_TYPE=Debug
-          -DBUILD_TESTING=ON
-          -DSQL_ENABLE_SANITIZERS=ON
-          -DCMAKE_COMPILE_WARNING_AS_ERROR=ON
-
-      - name: Build
-        run: cmake --build build-sanitized --parallel
-
-      - name: Test
-        run: ctest --test-dir build-sanitized --output-on-failure

DESIGN.md

@@ -52,5 +52,5 @@ The command-line process reads and writes table files in its current working dir
 ## Evidence
 
 The CTest suite covers end-to-end SQL behavior, parser safety, persistent randomized B+ tree images, page and WAL corruption, crash recovery, v1 migration equivalence, large rows, and deterministic in-memory B+ tree properties.
-CI runs release builds on Linux and macOS plus an AddressSanitizer and UndefinedBehaviorSanitizer build on Linux.
-The sanitizer job is a memory-safety regression gate, not evidence of production database readiness.
+CI runs a release build and the CTest suite on Linux.
+The AddressSanitizer and UndefinedBehaviorSanitizer build in the README is a local memory-safety check, not evidence of production database readiness.

README.md

@@ -60,7 +60,7 @@ ctest --test-dir build --output-on-failure
 The test executables verify SQL behavior, persistent incremental B+ tree splits, stable untouched pages, WAL ordering, dynamically enumerated crash boundaries, corruption rejection, idempotent recovery, migration equivalence, maximum-width rows, CLI inspection, parser safety, and both repository batch fixtures.
 Tests run in an isolated build directory, so they do not leave database files in the source tree.
 
-To run the same AddressSanitizer and UndefinedBehaviorSanitizer gate used by CI:
+To run the tests under AddressSanitizer and UndefinedBehaviorSanitizer:
 
 ```bash
 cmake -S . -B build-sanitized \

docs/storage-v2.md

@@ -159,7 +159,7 @@ The writer performs these boundaries in order:
 The statement is acknowledged only after step 6.
 Deterministic crash injection is available at the partial-WAL, WAL-write, WAL-fsync, per-page, data-fsync, WAL-truncate, and WAL-clear boundaries.
 The crash harness uses abrupt process termination and proves recovery logic and write ordering with the kernel page cache intact.
-It does not simulate physical media failure or loss of the operating system page cache, so power-loss durability rests on the documented fsync and directory-fsync contract plus Linux and macOS CI behavior.
+It does not simulate physical media failure or loss of the operating system page cache, so power-loss durability rests on the documented fsync and directory-fsync contract.
 
 ## Recovery