[AdaWorldAPI]

What

hubspo-store::log::Log (behind the lance feature) persists the resident Table from #22 as an append-only Lance log. It uses P-SPARSE-1's delta shape: nothing is updated in place, so there are no deletion vectors and the log is safe to compact.

• Record format: three record kinds, BORN (row), SET (row, lane, present, the lane's 32 bits) and DELETE (row). Every record is stamped with its version and owner.
• commit(table, batch): check the batch, append it as exactly one Lance version, then apply it to the table. The Lance version equals the table version. The log's version is compared before the append, which refuses a stale second writer, and again after it.
  • Two Lance appends never conflict, so this comparison is what enforces one writer per log.
  • Durable first: a failed append leaves the table unchanged.
• replay(owner, specs): rebuilds the table batch by batch through the same Table::apply. It refuses a foreign owner, an undecodable record, or a log whose Lance version is not its batch count.
• Table changes: it gains check() and specs(), and it refuses an empty batch (StoreError::EmptyBatch), since an empty batch would be a version that changes nothing.
• CI: a new job, store-lance, installs protoc (lance-encoding needs it at build time) and runs clippy and the tests with the feature. The default job stays fast.

The PR also records option (d) for OD-12 in the plan. lance-graph #1453 merged a read-only LDAP v3 handler over dir-sim, so stalwart's own LDAP directory backend could read dir-sim through it with no stalwart code change. The approved option (c) stands until two questions are settled: password checks (they go through the host's Authority) and dir-sim persistence.

Evidence

Tests (cargo test -p hubspo-store --features lance):

• 25 committed batches replay to an identical image, including deletes and negative values, and the log ends at exactly one Lance version per batch.
• A second, stale writer is refused before it applies anything, and the log afterwards holds only the first writer's batches.
• Refused and empty batches leave the log at its version.
• Replay under another owner is refused.

Disable runs:

disabled guard	result
pre-append version check	red
owner check on replay	red
I32 sign bit	red
deletes logged	red
apply only after the append	red
post-append version check	green

The post-append check stays green when disabled, and I kept it on purpose. It only fires when another writer appends between the pre-check and the write, a race no sequential test can schedule. The source says so at the check.

Locally: workspace fmt, clippy (--all-targets --no-deps -D warnings, default features and --features lance) and tests all pass. Rebased on main after #22; no other HubSPO-rs PR is open.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PPcakjk7ioQsnasmNDtc5z

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.