capture more tasks

Author: subtleGradient

.tasks/triage/TASK-161-resurrection-live-via-sentinel.md

@@ -0,0 +1,40 @@
+# TASK-161 — Test resurrection of live row via sentinel
+
+## Goal
+Verify Zig matches Rust/C oracle when a sentinel (cid='-1') change is applied to an already-live row.
+
+## Status
+- State: triage
+- Priority: high (cross-impl parity, CL semantics)
+
+## Context
+From Python `test_cl_merging.py::test_resurrection_of_live_thing_via_sentinel`:
+- A row exists and is live
+- A sentinel change arrives with higher CL
+- Expected: row stays live, CL is updated
+
+This tests the interaction between causal length and sentinel handling.
+
+## Files to Modify
+- `zig/harness/test-resurrection-parity.sh` (new)
+
+## Acceptance Criteria
+1. Test creates row on Site A
+2. Site B receives row via sync
+3. Site A deletes row (creates sentinel with CL=2)
+4. Site A re-inserts row (creates sentinel with CL=3)
+5. Meanwhile Site B still has live row (CL=1)
+6. Site B receives resurrection sentinel (CL=3)
+7. Verify: row is live on both, CL matches
+8. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_cl_merging.py`
+- Related: TASK-162, TASK-163, TASK-164
+- Gap backlog: `research/zig-cr/92-gap-backlog.md`
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-162-resurrection-dead-via-sentinel.md

@@ -0,0 +1,36 @@
+# TASK-162 — Test resurrection of deleted row via sentinel
+
+## Goal
+Verify Zig matches Rust/C oracle when a sentinel resurrects a previously-deleted row.
+
+## Status
+- State: triage
+- Priority: high (cross-impl parity, CL semantics)
+
+## Context
+From Python `test_cl_merging.py::test_resurrection_of_dead_thing_via_sentinel`:
+- A row is deleted (tombstone exists)
+- A sentinel change arrives with higher CL
+- Expected: row is resurrected (tombstone cleared)
+
+## Files to Modify
+- `zig/harness/test-resurrection-parity.sh` (new or extend)
+
+## Acceptance Criteria
+1. Create row, then delete it (CL=2 tombstone)
+2. Sync tombstone to Site B
+3. Site A resurrects via INSERT (CL=3 sentinel)
+4. Sync resurrection to Site B
+5. Verify: row is live on both sites
+6. Verify: clock table shows CL=3
+7. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_cl_merging.py`
+- Related: TASK-161, TASK-163, TASK-164
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-163-resurrection-live-via-column.md

@@ -0,0 +1,38 @@
+# TASK-163 — Test resurrection of live row via column value
+
+## Goal
+Verify Zig matches Rust/C oracle when a column update (not sentinel) arrives for an already-live row.
+
+## Status
+- State: triage
+- Priority: high (cross-impl parity, CL semantics)
+
+## Context
+From Python `test_cl_merging.py::test_resurrection_of_live_thing_via_non_sentinel`:
+- A row exists and is live
+- A column value change arrives with higher CL
+- Expected: column is updated, CL is updated
+
+This is the normal UPDATE case but with explicit CL verification.
+
+## Files to Modify
+- `zig/harness/test-resurrection-parity.sh` (new or extend)
+
+## Acceptance Criteria
+1. Create row with col='original' on Site A
+2. Sync to Site B
+3. Site A updates col='updated' (col_version=2)
+4. Site B receives update
+5. Verify: both have col='updated'
+6. Verify: clock shows correct col_version and CL
+7. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_cl_merging.py`
+- Related: TASK-161, TASK-162, TASK-164
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-164-resurrection-dead-via-column.md

@@ -0,0 +1,37 @@
+# TASK-163 — Test resurrection of deleted row via column value
+
+## Goal
+Verify Zig matches Rust/C oracle when a column update resurrects a deleted row.
+
+## Status
+- State: triage
+- Priority: high (cross-impl parity, CL semantics)
+
+## Context
+From Python `test_cl_merging.py::test_resurrection_of_dead_thing_via_non_sentinel`:
+- A row was deleted (tombstone exists)
+- A column value change arrives with higher CL
+- Expected: row is resurrected with that column value
+
+This is the tricky case where a column update must also resurrect.
+
+## Files to Modify
+- `zig/harness/test-resurrection-parity.sh` (new or extend)
+
+## Acceptance Criteria
+1. Create row, delete it (CL=2 tombstone)
+2. From a different site, send UPDATE with CL=3
+3. Verify: row is resurrected
+4. Verify: column has the new value
+5. Verify: clock shows CL=3
+6. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_cl_merging.py`
+- Related: TASK-161, TASK-162, TASK-163
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-165-out-of-order-delete-resurrect.md

@@ -0,0 +1,41 @@
+# TASK-165 — Test out-of-order sync with delete/resurrect interleaving
+
+## Goal
+Verify Zig handles out-of-order change arrival where deletes and resurrections interleave.
+
+## Status
+- State: triage
+- Priority: high (cross-impl parity, production scenario)
+
+## Context
+From Python `test_cl_merging.py::test_pr_299_scenario`:
+Real-world scenario where changes arrive out of order due to network delays.
+
+Sequence:
+1. Site A: INSERT row
+2. Site A: DELETE row
+3. Site A: INSERT row (resurrect)
+4. Site B receives changes in order: 1, 3, 2 (delete arrives last)
+
+Expected: Row should be live (resurrection has higher CL than delete).
+
+## Files to Modify
+- `zig/harness/test-resurrection-parity.sh` (new or extend)
+
+## Acceptance Criteria
+1. Simulate out-of-order arrival by manually ordering INSERT INTO crsql_changes
+2. Send: INSERT (CL=1), then RESURRECT (CL=3), then DELETE (CL=2)
+3. Verify: row is live (higher CL wins)
+4. Verify: idempotent (re-apply same changes, same result)
+5. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_cl_merging.py`
+- GitHub PR: #299 scenario
+- Related: TASK-161 through TASK-164
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-166-sentinel-omission-insert.md

@@ -0,0 +1,34 @@
+# TASK-166 — Test sentinel omission on INSERT
+
+## Goal
+Verify Zig does NOT emit sentinel (cid='-1') on normal INSERT operations.
+
+## Status
+- State: triage
+- Priority: high (wire format parity)
+
+## Context
+From Python `test_sentinel_omission.py::test_omitted_on_insert`:
+- INSERT should create clock entries for each column
+- INSERT should NOT create a sentinel row (cid='-1')
+- Sentinel is only for delete/resurrect tracking
+
+## Files to Modify
+- `zig/harness/test-sentinel-parity.sh` (new)
+
+## Acceptance Criteria
+1. INSERT a row into CRR table
+2. Query crsql_changes
+3. Verify: changes exist for each column
+4. Verify: NO change with cid='-1' exists
+5. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_sentinel_omission.py`
+- Related: TASK-167, TASK-168, TASK-169
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-167-sentinel-created-on-delete.md

@@ -0,0 +1,35 @@
+# TASK-167 — Test sentinel created on DELETE
+
+## Goal
+Verify Zig creates sentinel (cid='-1') when a row is deleted.
+
+## Status
+- State: triage
+- Priority: high (wire format parity)
+
+## Context
+From Python `test_sentinel_omission.py::test_created_on_delete`:
+- DELETE should create a sentinel row (cid='-1') in clock table
+- This sentinel marks the row as tombstoned
+- The sentinel has a CL value for resurrection comparison
+
+## Files to Modify
+- `zig/harness/test-sentinel-parity.sh` (new or extend)
+
+## Acceptance Criteria
+1. INSERT a row into CRR table
+2. DELETE the row
+3. Query crsql_changes
+4. Verify: sentinel change with cid='-1' exists
+5. Verify: sentinel has correct CL (should be 2)
+6. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_sentinel_omission.py`
+- Related: TASK-166, TASK-168, TASK-169
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-168-sentinel-not-on-replace.md

@@ -0,0 +1,35 @@
+# TASK-168 — Test sentinel NOT created on INSERT OR REPLACE
+
+## Goal
+Verify Zig does NOT create sentinel on INSERT OR REPLACE.
+
+## Status
+- State: triage
+- Priority: medium (edge case)
+
+## Context
+From Python `test_sentinel_omission.py::test_not_created_on_replace`:
+- INSERT OR REPLACE is logically an UPDATE (or INSERT if new)
+- It should NOT create a sentinel
+- Only explicit DELETE creates sentinel
+
+## Files to Modify
+- `zig/harness/test-sentinel-parity.sh` (new or extend)
+
+## Acceptance Criteria
+1. INSERT a row
+2. INSERT OR REPLACE same PK with different values
+3. Query crsql_changes
+4. Verify: column changes exist
+5. Verify: NO sentinel (cid='-1') exists
+6. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_sentinel_omission.py`
+- Related: TASK-166, TASK-167, TASK-169
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-169-sentinel-not-on-merge.md

@@ -0,0 +1,38 @@
+# TASK-169 — Test sentinel NOT created during merge (sync)
+
+## Goal
+Verify Zig does NOT create new sentinel when applying remote changes.
+
+## Status
+- State: triage
+- Priority: high (sync correctness)
+
+## Context
+From Python `test_sentinel_omission.py::test_not_created_on_merge`:
+- When applying changes via INSERT INTO crsql_changes
+- We should NOT create NEW sentinels
+- We should only propagate existing sentinels
+
+Creating sentinels during merge would corrupt CL tracking.
+
+## Files to Modify
+- `zig/harness/test-sentinel-parity.sh` (new or extend)
+
+## Acceptance Criteria
+1. Site A: INSERT row
+2. Sync to Site B via crsql_changes
+3. Verify: Site B has row but NO sentinel in its clock
+4. Site A: DELETE row (creates sentinel CL=2)
+5. Sync delete to Site B
+6. Verify: Site B has sentinel with CL=2 (propagated, not new)
+7. Zig and Rust/C oracle produce identical results
+
+## Parent Docs / Cross-links
+- Python test: `py/correctness/test_sentinel_omission.py`
+- Related: TASK-166, TASK-167, TASK-168
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)

.tasks/triage/TASK-170-fk-between-crr-tables.md

@@ -0,0 +1,42 @@
+# TASK-170 — Test foreign keys between CRR tables
+
+## Goal
+Verify Zig handles foreign key constraints between CRR tables correctly during sync.
+
+## Status
+- State: triage
+- Priority: high (real-world apps have FKs)
+
+## Context
+No existing tests verify FK behavior between CRR tables. Real apps commonly have:
+- Parent/child relationships (orders → line_items)
+- Many-to-many via junction tables
+- Self-referential FKs (org hierarchy)
+
+Key questions:
+1. What happens when child row arrives before parent?
+2. Does FK violation during merge fail or defer?
+3. Are FK constraints even compatible with CRRs?
+
+## Files to Modify
+- `zig/harness/test-fk-crr.sh` (new)
+
+## Acceptance Criteria
+1. Create parent CRR table with PK
+2. Create child CRR table with FK to parent
+3. Insert parent, then child — works
+4. Sync child to Site B (parent not yet synced)
+5. Document behavior (fail? deferred? ignored?)
+6. Sync parent to Site B
+7. Verify FK constraint now satisfied
+8. Zig and Rust/C oracle produce identical results (or document difference)
+
+## Parent Docs / Cross-links
+- Related: TASK-171 (cascading deletes)
+- Gap backlog: `research/zig-cr/92-gap-backlog.md`
+
+## Progress Log
+- 2025-12-22: Created from gap analysis.
+
+## Completion Notes
+(Empty until done.)