Page-state rollback can overwrite concurrent page edits

[jzjzzzzzzz]

Summary

project_page_state.py can overwrite a concurrent in-place edit while rolling back a multi-page projection.

Reproduction

1. Start a page-state projection that changes at least two pages.
2. Let the first page publish successfully.
3. Modify that published page in place from another process, preserving its inode.
4. Make publication of a later page fail.

Actual behavior

Rollback recognizes the page only by the transaction's published inode, unlinks it, restores the original before-image, and removes the recovery lock. The concurrent writer's bytes are lost.

A regression reproducer observes:

exit_code=1
concurrent_edit_preserved=False
restored_to_old_bytes=True
lock_exists=False

Expected behavior

Rollback must behave as a compare-and-swap against the exact verified after-image. If the canonical page's bytes or stable identity have changed since publication, it must:

• preserve the concurrent page bytes;
• preserve the original rollback image;
• retain the writer lock and recovery journal with rollback-required status;
• require reconciliation instead of declaring rollback complete.

Impact

This is a data-loss issue: an unrelated editor can successfully write a page and have that edit silently replaced by a later failure elsewhere in the projection batch.

[KimGLee]

Thank you for reporting this issue and for following it with #60. The direction taken in the PR — binding rollback to the published after-image, detecting drift, and preserving recovery evidence instead of silently discarding it — is valuable and correctly surfaces the immediate data-loss risk.

This also exposes a deeper architectural boundary that is already covered by the Roadmap.

Cambium's intended multi-agent model is not multiple agents writing the same canonical file concurrently. Parallel work happens in disjoint batches and isolated workspaces; a single Integrator serializes writes into canonical state. The Core transaction layer is the safety net underneath that model: if isolation fails, or an editor or other non-cooperating process changes a canonical page, Core must fail closed and must not silently destroy bytes it can no longer prove belong to its own transaction.

flowchart TD
    K["Kernel / Profile / Required Queue"] --> O["Operation Capability Registry"]
    O --> A["Assignment State"]
    A --> W["Isolated Workers<br/>parallel, batch-private work"]
    W --> I["Single-writer Integrator<br/>serial canonical integration"]
    I --> C["Shared Core Transaction<br/>lock + byte binding + journal + recovery"]
    C --> R["Canonical Repository"]
    E["External or non-cooperating writer"] -. "unexpected drift" .-> C
    C --> F["Fail closed<br/>preserve live bytes + rollback image + journal/lock"]

Loading

In Roadmap terms, #59 is a concrete node connecting several planned layers:

• Phase 0 — Core and Packaging Stabilization already calls for negative fixtures covering concurrent writers and interrupted writes.
• Phase 2 — Guarded Local Beta requires writes to use exact revisions and SHAs, locks, receipts, and interruption recovery.
• The Reference Execution Runtime and its Integrator Loop prevent legitimate managed agents from colliding by design.
• Parallel Workers and Independent Review add isolated workspaces only after the single-writer Integrator is reliable.

The responsibility split is therefore:

• Runtime and Host Adapter: prevent legitimate agents from overlapping write scopes.
• Integrator: remain the sole canonical-state writer and merge one batch at a time.
• Core transaction/recovery: if isolation is broken or an external edit appears, preserve the live bytes and recovery evidence, then require reconciliation instead of performing an unsafe destructive rollback.

For #60, the after-image and recovery-journal work remains useful. It does not need to grow into a complete multi-agent runtime or attempt to emulate a portable transactional filesystem inside project_page_state.py. Where exact ownership can no longer be proven, the durable behavior should be to stop, retain the live page, rollback image, journal, and lock, and enter a reconciliation-required state.

There is no need to withdraw or close either this issue or #60. Please keep both open: they provide the concrete failure case and implementation exploration for this Roadmap node. In the upcoming Roadmap implementation work, this safety property will be incorporated into the shared Core transaction/reconciliation layer beneath the Integrator; the final implementation boundary may therefore be generalized beyond this one projector.

Thanks again — this is a useful finding precisely because it connects a local data-loss reproduction to the larger multi-agent execution and serial-integration architecture.

[jzjzzzzzzz]

Thank you for the detailed architectural context. The responsibility split is clear, and I agree with the intended boundary:

• isolated workers and the Host Adapter prevent managed write-scope overlap;
• the Integrator remains the sole serial writer to canonical state;
• Core transaction/recovery is the fail-closed backstop for isolation failures and non-cooperating writers.

I will keep #59 and #60 open as requested. I will also keep #60 scoped to the concrete safety invariant demonstrated by the reproducer: once the projector has verified and published its after-image, rollback may remove that canonical page only while it can still prove the page is exactly that owned after-image. If the proof fails, it preserves the live page, original rollback image, journal, and lock and requires reconciliation.

I agree that this should ultimately live in the shared Core transaction/reconciliation layer rather than become projector-specific transactional infrastructure. The PR can serve as the focused regression fixture and implementation exploration, and I am happy to adapt it when the shared Core boundary is introduced during the Roadmap work.

Thanks for connecting the local failure mode to the broader execution architecture.