chore: capture parity edge-case decisions for Tom

Author: subtleGradient

.wishes/blocked-on-tom/zig-empty-blob-pk-encoding-parity.md

@@ -0,0 +1,40 @@
+# Wish: Decide empty BLOB PK encoding parity (WF-028)
+
+## Context
+Our Zig extension currently diverges from the Rust/C oracle for **empty BLOB primary keys** (PK value `X''`) in the **encoded `pk` blob** emitted by `crsql_changes`.
+
+This shows up in the parity suite as:
+- `zig/harness/test-pk-blob-parity.sh` → **WF-028 FAIL**
+
+## Repro
+```bash
+cd /Users/tom/Developer/effect-native/cr-sqlite
+bash zig/harness/test-pk-blob-parity.sh
+```
+
+Current observed output:
+- Zig: `0105`
+- Rust/C: `0104`
+
+## Why this matters
+The `pk` encoding is part of the sync wire format. Divergence means:
+- Zig↔Rust/C cross-impl sync might mis-address rows for this edge case
+- future tooling/tests that assume byte-identical PK encoding will keep failing
+
+## Recommendation
+**Fix Zig to match Rust/C**.
+
+Even though empty BLOB PKs are rare, this is an encoding-level contract, and it’s cheap to keep deterministic parity.
+
+## Likely implementation scope (if approved)
+- Investigate `zig/src/pack_columns.zig` handling of empty BLOBs
+- Compare to `core/rs/core/src/pack_columns.rs` behavior
+- Ensure `X''` is distinguished from `NULL` and matches oracle’s tag/length encoding
+
+## Cross-links
+- Existing triage task: `.tasks/triage/TASK-203-empty-blob-pk-encoding-divergence.md`
+- Test: `zig/harness/test-pk-blob-parity.sh` (WF-028)
+
+## Decision requested from Tom
+- Accept divergence (document + adjust tests), OR
+- Approve parity fix in Zig (recommended)

.wishes/blocked-on-tom/zig-merge-atomicity-vs-lenient-schema-mismatch.md

@@ -0,0 +1,58 @@
+# Wish: Decide behavior for batch apply when some incoming changes are ignorable
+
+## Context
+We recently decided **unknown columns during sync are ignored** (lenient behavior) to support rolling upgrades.
+
+That decision interacts with our existing **merge atomicity** expectations.
+
+Today:
+- `zig/harness/test-merge-atomicity.sh` reports **2 failing checks**
+- Those failures are caused by using “unknown column” as the error injection mechanism, but unknown columns are now **ignored**, so the batch doesn’t fail and the first row legitimately persists.
+
+## Repro
+```bash
+cd /Users/tom/Developer/effect-native/cr-sqlite
+bash zig/harness/test-merge-atomicity.sh
+```
+
+Failing checks:
+- Test 2: “Invalid column in batch causes entire statement to fail”
+- Test 7: “Base table integrity after failed batch”
+
+## What’s the actual decision point?
+When applying a batch of incoming changes (often shipped in a single SQL statement with multiple VALUES rows):
+
+If some rows are **ignored by policy** (unknown column), do we want:
+
+1) **Apply the valid subset** (current behavior)
+   - “best effort apply”
+   - matches lenient schema mismatch policy
+
+2) **Fail the statement / rollback entire batch** if *any* row is unapplicable
+   - stricter atomicity semantics
+   - but conflicts with “ignore unknown columns” unless we special-case
+
+## Recommendation
+**Keep applying the valid subset** when the “failure” is an ignorable policy case (unknown column).
+
+Then update `test-merge-atomicity.sh` to inject errors using something that remains a hard error even under lenient schema mismatch, e.g.
+- invalid table name
+- invalid PK blob / malformed pk encoding
+- invalid site_id length (if we decide to add validation)
+
+This maintains a useful atomicity guarantee:
+- real errors rollback
+- intentionally ignored changes don’t poison the whole batch
+
+## Likely follow-up work (if approved)
+- Update `zig/harness/test-merge-atomicity.sh` to align with the chosen policy
+- Possibly add a new test that explicitly validates “unknown column rows are ignored but known columns still apply” (this is now part of the contract)
+
+## Cross-links
+- Related decision already implemented: `.tasks/done/TASK-186-schema-mismatch-unknown-column-behavior.md`
+- Existing spec task: `.tasks/done/TASK-087-spec-merge-atomicity.md`
+- Test: `zig/harness/test-merge-atomicity.sh`
+
+## Decision requested from Tom
+- Confirm that “unknown columns ignored” implies “best effort apply” within a batch (recommended)
+- Or require strict all-or-nothing batch failure semantics even for unknown columns

research/zig-cr/92-gap-backlog.md

@@ -60,6 +60,10 @@ No active tasks. Core sync functionality is complete and working.
 ### Known Limitations
 - **crsql_changes SELECT perf**: ~2-7x slower on wide tables vs Rust/C (COUNT is fast, SELECT * is slow)
 
+### Blocked on Tom (edge-case parity decisions)
+- `./.wishes/blocked-on-tom/zig-empty-blob-pk-encoding-parity.md` — decide whether to fix empty BLOB PK encoding (recommended: fix parity)
+- `./.wishes/blocked-on-tom/zig-merge-atomicity-vs-lenient-schema-mismatch.md` — decide atomicity semantics under lenient unknown-column policy (recommended: best-effort apply)
+
 ### Completed Round 76 (2025-12-25) — seq divergence + schema mismatch fixes
 - [x] **TASK-199**: Fix seq value divergence (Zig=1, Rust=0) ✓
   - Root cause: `crsqlAfterInsertFunc` called `getNextSeq()` unconditionally for `maybeMarkReinserted`, wasting seq=0