Publishing & Revision Workflows

CopyPatch v2 implements a two-stage publishing model (Draft vs. Published) per locale, enforced by atomic compare-and-swap (CAS) revision counters and role-based permissions.

1. Draft vs. Published Stages

2. Step-by-Step Lifecycle

1. Inline Editing: An editor enters ?copypatch=1, makes text modifications directly on the live page, and clicks Save Draft (⌘S).
2. Draft Persistence: The backend persists the modified string map into the draft state in SQLite or PostgreSQL, incrementing the draftRevision counter.
3. Review & Staging: Clients and stakeholders preview the staged copy in real-time on the live layout before approving.
4. Publishing to Live: An authorized team member with the publisher role clicks Publish. The backend atomically promotes the draft into the published snapshot and increments publishedRevision.
5. Live Distribution: Subsequent SSR/RSC reads and client polling immediately receive the new published snapshot.

3. Optimistic Concurrency Control (OCC / CAS)

When multiple team members collaborate on the same locale, CopyPatch prevents silent overwrites:

• Every draft or publish request transmits both expectedPublishedRevision and expectedDraftRevision.
• If another editor published or saved changes in the background, the server rejects the request with HTTP 409 REVISION_CONFLICT.
• The response includes the latest snapshot so the editor's UI can cleanly reconcile changes without data loss.

// 409 Conflict Response Payload
{
  "error": {
    "code": "REVISION_CONFLICT",
    "message": "The active locale was updated by another editor since your session began.",
    "currentPublishedRevision": 14,
    "currentDraftRevision": 18,
    "expectedPublishedRevision": 12,
    "expectedDraftRevision": 15,
    "latest": {
      "revision": 14,
      "content": {
        "hero.title": "Updated headline by team member"
      }
    }
  }
}

4. Audit & History Notice

Design Note: CopyPatch optimizes for lightweight, high-performance persistence and does not maintain an unbounded historical audit log inside its core tables. If immutable compliance audit trails are required, log mutation events within your host application's audit pipeline or database replication stream.