alkblobs/tasks/review-wave-4.md

id, name, status, depends_on, scope, risk, impact, level, tags

id	name	status	depends_on	scope	risk	impact	level	tags
review-wave-4	Wave 4 review gate — the postgres engine vs the contract	pending	suite-column-postgres	narrow	low	phase	review	wave-4 review

Description

The wave-4 review gate — the engine-wave review shape (docs/plans/implementation.md §Review gates: "engine-vs-contract conformance"), before wave 5 decomposes. The gate reads the implementation against the pinned ADR text line by line (the wave-1/2/3 gates' method).

Gate checks:

• Engine-vs-contract conformance: the suite column green against dockerized postgres (server-less runs skip cleanly — a skip never substitutes for acceptance); the engine-state clause families contract-tested per the applicability row (ADR-012 §5's postgres row — every family yes); virgin-store semantics; the size metadata-only discipline (the size-column probe never loads the value blob).
• The postgres posture vs ADR-007: the B5 deltas carried as requirements, not hedges — the synchronous_commit parity knob (configurable, per-connection wiring, default on); pooled connections with per-connection prepared-statement discipline (statements die with sessions); autovacuum + fillfactor tuning stated in the module doc; the ~40× small-tier storage overhead accepted and documented; the B5 tuning numbers recorded as POC-derived posture defaults (ADR-007 §6's deferred-cost pattern).
• The sweep-safety proof vs ADR-007 §5: list() complete and well-formed as a stable MVCC-snapshot cursor over a vacuuming table; the batch-delete helper (key = ANY($1)) contract-tested; the exact-count sweep-outcome rows green against the server.
• The seam families vs ADR-010 §2 / ADR-012 §4/§5: the full clause families on postgres (the fleet host) — ensure_gc_schema (both tables, the embedder's liveness table never created), window_stage/window_take (the sqlite semantics' dialect twin), the joint tx ownership rule honored in the JointTx shape (the store holds; the engine contributes), pin_commit's atomicity (publish + protection in one step, zero residue on failure), pin_renew's never-resurrect semantics, pin_check's classification-only discipline, arbitrate's finger-lock fold, the advisory lock's ADR-013 §2 lease semantics (atomic test-and-set, session-scoped holdership, same-connection release). Fleet activation absent by construction — no fleet: parameter, no store-core fleet wiring (wave 6); the clause bodies exist and are contract-tested per applicability.
• The non-fleet posture vs ADR-012 §3: the constructors are implicitly fleet: false — the in-process protocol verbatim; the recorded posture names wave 6's slotting-in as a non-event.
• Async/blocking discipline: tokio-postgres natively async — no spawn_blocking seam (the sqlite discipline does not carry); no blocking I/O on the async path; the pool is the concurrency posture; no unwrap/expect outside tests.
• Named design points audited as resolved (each recorded in its task's Notes): the schema name + quoted-identifier boundary; the pool default size; the prepared-statement discipline; the DSN + opts constructor shape; the virgin-store tolerance split; the list-cursor fetch shape; the timestamp encoding; the JointTx concrete type; the pin_renew successor-time source; the lock key + scope; the lease's connection holding.
• Family conventions: no comments in code (doc comments on public API fine), thiserror, tokio-only async, no unwrap/expect outside tests, naming, one-module-per-file re-export shape, the #![allow(dead_code)] scope notes matching their remaining scope (the batch-delete helper's wave-6 note intact).
• Gates green: cargo test (default), cargo test --features mem, cargo test --features postgres (server-less: skipping), cargo test --all-features, cargo check --no-default-features --features postgres (the pg-pure build), cargo clippy --all-targets -- -D warnings (default + --features postgres + --all-features), cargo fmt --check.

Findings are fixed inline where cheap, or recorded as wave-5 amendments where they shape the next decomposition. The gate's completion is what unblocks wave 5's decomposition.

Acceptance Criteria

• Every gate check above read and verified against the cited ADR text (not from memory of it)
• Named design points each decided, recorded, and consistent with the specs
• Findings fixed inline or recorded as wave-5 amendments with owners
• All gates re-run green after any fixes
• Wave 5 decomposition unblocked (recorded in this task's Summary)

References

• docs/plans/implementation.md (§Wave 4, §Review gates — engine wave reviews)
• docs/architecture/decisions/007-two-kv-engines-sqlite-and-postgres.md
• docs/architecture/decisions/010-backend-io-seams-and-fleet-state-home.md §2
• docs/architecture/decisions/012-pre-decomposition-consistency-rulings.md §3/§4/§5/§6.6/§6.7
• docs/architecture/decisions/013-family-composition-reactive-boundary-and-feature-graph.md §2/§4
• docs/architecture/store-api.md
• tasks/review-wave-3.md (the gate method; the structural twin's gate)

Notes

To be filled by the review agent

Summary

To be filled on completion