go-cms-resource-revisions

Implements resource revision history with versioned snapshots, restore, and purge in Go CMS.

Updated Jun 15, 2026
One-click install
npx skills add https://github.com/vernal96/go-cms --skill go-cms-resource-revisions-vernal96
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: go-cms-resource-revisions
Source: https://github.com/vernal96/go-cms/tree/main/.codex/skills/go-cms-resource-revisions
Command: npx skills add https://github.com/vernal96/go-cms --skill go-cms-resource-revisions-vernal96

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It defines how to design and implement resource revision history in the Go CMS backend so that every versionable mutation is captured as an immutable snapshot, stale edits fail safely, and old versions can be restored or purged without corrupting current state. ## Core Features & Use Cases - Versioned Snapshots: Append-only revision records with monotonic version counters, optimistic locking, and per-revision author metadata stored in PostgreSQL JSONB. - Safe Restore Semantics: Restoring an old version creates a new version validated against current runtime rules instead of rewriting history. - Retention and Purge: Resource-local and global history purge operations that never reset current resource versions, plus policy-aware revision handling for bulk LibraryItems. - Use Case: When adding a History tab to the resource editor, use this Skill to design the revision table, transaction boundary, API endpoints, and authorization checks so editors can view, restore, and purge past versions safely. ## Quick Start Ask the AI to design the revision storage and restore flow for a Go CMS resource following the revision architecture rules in this Skill.

Frequently Asked Questions about go-cms-resource-revisions

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement resource revision history in a Go CMS backend?▼

Store append-only revision snapshots in a single PostgreSQL table with indexed metadata columns and a JSONB snapshot. Each versionable mutation increments the resource version and inserts the revision inside the same database transaction.

How should restoring an old resource version work?▼

Restore never rewrites history; it creates a new version whose state is based on the old snapshot. The snapshot is projected into a candidate resource and validated against current template, field, widget, and path rules before persistence.

Does purging revision history reset the resource version counter?▼

No, purging history must not alter current resource state or reset its version counter. If version 28 loses all history, the next mutation still creates version 29, keeping the counter monotonic.

Should revision snapshots include database IDs and audit timestamps?▼

No, snapshots capture semantic state such as slug, template fields, and widget code, area, and params. Transient metadata like CreatedAt, UpdatedBy, or historical primary keys must not be restored from a snapshot.

When should LibraryItems skip revision creation?▼

Library collections can be extremely large or bulk-imported, so revision creation for LibraryItems must be policy and configuration aware. Bulk imports should not generate unbounded history just because tree resources do.