================================================================================
COLLABTUNES ZIP CHECKPOINT POLICY
Version: 1.0 | Date: 5_13_26 | Status: AUTHORITATIVE
Owner: Mixed Claude / Tom
Purpose: Defines when to checkpoint, naming rules, rollback hierarchy,
         authority preservation rules, and backup standards.
================================================================================

================================================================================
SECTION 1 — WHEN TO CREATE A ZIP CHECKPOINT
================================================================================

MANDATORY CHECKPOINTS — always create, no exceptions:
────────────────────────────────────────────────────────

TRIGGER M1: Pre-run baseline
  WHEN:     Before any SGC-1 or SGC-2 LIVE_RUN
  WHAT:     Snapshot of current /outputs/ and canon folders
  PURPOSE:  Rollback point if run corrupts or produces bad data
  TYPE:     PRE_RUN_BASELINE

TRIGGER M2: Post-canon update
  WHEN:     Any time a file in 02_CANON/ or 03_RATINGS/ is modified
  WHAT:     Full snapshot of 02_CANON/, 03_RATINGS/, 05_URL_MAPS/
  PURPOSE:  Canon is irreplaceable — always checkpoint before and after
  TYPE:     CANON_CHECKPOINT

TRIGGER M3: Post-stabilization cycle completion
  WHEN:     After all phases of MASTER_DEPLOYMENT_SEQUENCE are complete
  WHAT:     Full snapshot of all production folders
  PURPOSE:  Record of stable state at end of cycle
  TYPE:     STABILIZATION_CHECKPOINT

TRIGGER M4: Pre-deployment package creation
  WHEN:     Immediately before creating 07_DEPLOYMENT/ package
  WHAT:     Full snapshot of all canon + generator inputs
  PURPOSE:  Rollback if deployment package creation goes wrong
  TYPE:     PRE_DEPLOYMENT_BACKUP

TRIGGER M5: End of session (when any production file was touched)
  WHEN:     End of any work session where AUTHORITATIVE+ files were changed
  WHAT:     Targeted ZIP of all changed files
  PURPOSE:  Session-level rollback point
  TYPE:     SESSION_CHECKPOINT

CONDITIONAL CHECKPOINTS — create when indicated:
─────────────────────────────────────────────────

TRIGGER C1: Before resolving a CRITICAL blocker
  WHEN:     About to implement gate fix or critical routing change
  WHAT:     Snapshot of affected HTML/JS files
  PURPOSE:  If fix makes things worse, rollback immediately

TRIGGER C2: Before bulk rename / naming normalization
  WHEN:     About to rename multiple files for naming canon compliance
  WHAT:     Snapshot of all files being renamed
  PURPOSE:  Undo entire rename batch if needed

TRIGGER C3: Before generator runs
  WHEN:     First time running generator in any session
  WHAT:     Snapshot of all generator input files
  PURPOSE:  Inputs are the ground truth — protect them

TRIGGER C4: After receiving files from Tom
  WHEN:     New files uploaded / provided by Tom
  WHAT:     ZIP of newly received files
  PURPOSE:  Archive intake state before processing

SKIP CHECKPOINTS — do not create for:
───────────────────────────────────────
  - Read-only operations (SGC DRY_RUN, file listing, audit reads)
  - Changes to staging/working files only (09_HTML_PROTOTYPES/, 10_QA/)
  - Changes to test fixtures only (15_GATHERING_TOOLS/tests/)
  - Duplicate of a checkpoint that already exists with same content

================================================================================
SECTION 2 — ZIP NAMING STRUCTURE
================================================================================

STANDARD FORMAT:
  {FILE_COUNT}_{FILE_TYPES}_{CATEGORY}_{DESCRIPTION}_{DATE}.zip

FIELD RULES:

FILE_COUNT:
  Integer count of files contained in the ZIP.
  Count every file including the manifest. Accurate count required.
  Example: 43 (not "40+" or "~40")

FILE_TYPES:
  Uppercase tokens separated by underscores.
  Use only types actually present: TXT, ZIP, HTML, PY, JSON, PDF
  Example: TXT_JSON (if ZIP contains only TXT and JSON files)
  Example: HTML_TXT_ZIP (if ZIP contains HTML, TXT, and nested ZIPs)

CATEGORY:
  One of the following checkpoint type tokens:
  PRE_RUN_BASELINE
  CANON_CHECKPOINT
  STABILIZATION_CHECKPOINT
  PRE_DEPLOYMENT_BACKUP
  SESSION_CHECKPOINT
  QA_OUTPUTS
  GENERATOR_INPUTS
  DEPLOYMENT_PACKAGE
  ROLLBACK

DESCRIPTION:
  3-6 words in UPPERCASE_UNDERSCORE describing what's inside.
  Be specific. "MISC" and "BACKUP" are banned.
  Good: CANON_AND_RATINGS_ALL_PRODUCTION
  Bad:  BACKUP_STUFF

DATE:
  M_D_YY format. Always include.

FULL EXAMPLES:
  11_TXT_CANON_CHECKPOINT_02_CANON_03_RATINGS_05_URL_MAPS_5_13_26.zip
  43_PY_TXT_ZIP_STABILIZATION_CHECKPOINT_FULL_SGC_SYSTEM_5_13_26.zip
  6_HTML_TXT_PRE_DEPLOYMENT_BACKUP_GENERATOR_INPUTS_5_13_26.zip
  22_TXT_JSON_SESSION_CHECKPOINT_AFTER_BLOCKER_L01_FIX_5_13_26.zip
  5_TXT_QA_OUTPUTS_DEPLOYMENT_AUDIT_CYCLE_3_5_13_26.zip

BANNED PATTERNS (reject any ZIP with these in the name):
  final, backup, new, fixed, temp, misc, stuff, test, old, updated,
  copy, v2, revised, latest, current, export, untitled

================================================================================
SECTION 3 — ROLLBACK HIERARCHY
================================================================================

When something goes wrong and you need to roll back, follow this hierarchy.
Always try the most recent rollback point first.

LEVEL 1 — SAME-SESSION ROLLBACK (fastest, most precise)
──────────────────────────────────────────────────────────
Source:   SESSION_CHECKPOINT or TRIGGER-C checkpoint from current session
Use when: A change made in the current session caused a problem
Action:   Extract the relevant files from the SESSION_CHECKPOINT ZIP
          Overwrite the problematic files
          Do NOT overwrite files not involved in the problem
Applies to: Individual file changes, small batches

LEVEL 2 — CYCLE ROLLBACK (moderate scope)
───────────────────────────────────────────
Source:   STABILIZATION_CHECKPOINT from end of last completed cycle
Use when: Current cycle's changes are all bad and need to be reverted
Action:   Identify which folders were changed this cycle
          Restore those folders from STABILIZATION_CHECKPOINT
          Do NOT restore outputs/ or logs/ (those are run artifacts)
Applies to: Full stabilization cycle rollback

LEVEL 3 — PRE-RUN BASELINE ROLLBACK
──────────────────────────────────────
Source:   PRE_RUN_BASELINE from before current SGC run
Use when: SGC run produced bad data that corrupted /outputs/
Action:   Clear /outputs/ and restore from PRE_RUN_BASELINE
Applies to: SGC output corruption only

LEVEL 4 — DEPLOYMENT ROLLBACK (nuclear option)
────────────────────────────────────────────────
Source:   PRE_DEPLOYMENT_BACKUP
Use when: Deployment broke the live site or produced wrong output
Action:   Restore all production files from PRE_DEPLOYMENT_BACKUP
          Redeploy from restored state
Applies to: Live site reversal
Critical:   This affects real users. Tom must authorize Level 4 rollback.

ROLLBACK RULES:
  1. Never roll back without first documenting what went wrong.
  2. Create a blocker entry for the problem that triggered the rollback.
  3. After rollback, the problem must be fixed in a new cycle — not ignored.
  4. Level 4 requires Tom authorization.
  5. Always verify the rollback worked (re-run SGC or manual spot-check).

================================================================================
SECTION 4 — AUTHORITY PRESERVATION RULES
================================================================================

The checkpoint system exists to protect canon authority layers.
These rules govern how authority is preserved across checkpoints.

RULE A1: LOCKED files are untouchable
──────────────────────────────────────
Files at LOCKED authority status:
  - Must be included in every CANON_CHECKPOINT
  - Must never be overwritten by a rollback to a state where they were WORKING
  - If a LOCKED file must change: Tom creates new VOL with new date, new review
  - The prior LOCKED version is archived as REFERENCE, never deleted

RULE A2: AUTHORITATIVE files require new VOL on change
────────────────────────────────────────────────────────
When an AUTHORITATIVE file is modified:
  1. Create checkpoint BEFORE modification (TRIGGER M2)
  2. Increment VOL number
  3. Add new date stamp
  4. Old file status → REFERENCE
  5. New file status → AUTHORITATIVE
  6. Create checkpoint AFTER modification
  All these steps are atomic — partial execution is not allowed.

RULE A3: Checkpoint ZIPs are read-only after creation
───────────────────────────────────────────────────────
Once a checkpoint ZIP is created:
  - It is never modified
  - It is never renamed (except to add _ARCHIVE suffix if superseded)
  - It is never deleted (only archived to 13_SOURCE_ZIPS/)
  - Its manifest is verified before first use in any rollback

RULE A4: Sensitive files never enter checkpoint ZIPs
──────────────────────────────────────────────────────
Files matching SENSITIVE_FILENAME_PATTERNS:
  - DEFAMATION_RISK_REGISTRY_*
  - CREATOR_INTERVIEW_TRANSCRIPT_*
  - MASTER_DUMPS_*
These files must NEVER be included in checkpoint ZIPs.
If a checkpoint operation would include them: skip those files, note the skip
in the manifest.

RULE A5: Checkpoint manifest accuracy is mandatory
────────────────────────────────────────────────────
Every checkpoint ZIP must contain a manifest listing every file inside it.
A checkpoint with no manifest or an inaccurate manifest is considered CORRUPT.
A CORRUPT checkpoint cannot be used for rollback until manifest is rebuilt.

================================================================================
SECTION 5 — PRODUCTION VS STAGING BACKUP RULES
================================================================================

PRODUCTION FOLDERS (require full checkpoint protection):
─────────────────────────────────────────────────────────
  02_CANON/               — checkpoint on every change
  03_RATINGS/             — checkpoint on every change
  05_URL_MAPS/            — checkpoint on every change
  06_NAV_STABILIZATION/   — checkpoint on every change
  07_DEPLOYMENT/          — checkpoint before every deployment package update

SEMI-PRODUCTION FOLDERS (checkpoint on significant change):
────────────────────────────────────────────────────────────
  01_LIVE_CAPTURE/        — checkpoint after each SGC-1 run
  11_REGISTRY/            — checkpoint on each VOL increment
  12_MANIFESTS/           — checkpoint when manifests are updated

STAGING FOLDERS (checkpoint optional — session end only):
──────────────────────────────────────────────────────────
  08_PLACEHOLDERS/        — session end only
  09_HTML_PROTOTYPES/     — session end only
  10_QA/                  — session end only
  14_GENERATED_OUTPUT/    — DO NOT checkpoint (generator will regenerate)
  15_GATHERING_TOOLS/     — only checkpoint when code changes are made

ARCHIVE FOLDERS (no backup required — already archives):
─────────────────────────────────────────────────────────
  13_SOURCE_ZIPS/         — this IS the archive; no further backup needed
  00_OPERATIONAL_RULES/   — LOCKED content; backed up in first-ever checkpoint

BACKUP FREQUENCY SUMMARY:
  Production:       Every change → immediate checkpoint
  Semi-production:  Significant change → checkpoint same session
  Staging:          Session end → session checkpoint
  Generator output: No checkpoint (regenerate as needed)
  Archive:          No checkpoint (archive is its own backup)

================================================================================
SECTION 6 — CHECKPOINT LOG
================================================================================

Keep a running log of all checkpoints created.
Format: DATE | TYPE | FILENAME | FILES_INSIDE | NOTES

DATE      | TYPE                    | FILENAME                                           | COUNT | NOTES
----------|-------------------------|----------------------------------------------------|-------|------
5_13_26   | STABILIZATION_CHECKPOINT| 5_TXT_STABILIZATION_CONTROL_LAYER_5_13_26.zip      | 5     | First control tower package
5_13_26   | STABILIZATION_CHECKPOINT| 4_TXT_DEPLOYMENT_OPS_SYSTEM_5_13_26.zip            | 4     | Deployment ops system
          |                         |                                                    |       |
          |                         |                                                    |       |
          |                         |                                                    |       |

================================================================================
SECTION 7 — CHECKPOINT QUICK-REFERENCE CARD
================================================================================

SITUATION                              → ACTION
────────────────────────────────────────────────────────────────────────────────
About to run SGC-1 or SGC-2 LIVE      → M1: PRE_RUN_BASELINE checkpoint
About to edit any 02_CANON file        → M2: CANON_CHECKPOINT before + after
Finished a full stabilization cycle    → M3: STABILIZATION_CHECKPOINT
About to create deployment package     → M4: PRE_DEPLOYMENT_BACKUP
End of session (canon was touched)     → M5: SESSION_CHECKPOINT
About to fix a CRITICAL blocker        → C1: Targeted checkpoint of affected files
About to bulk-rename files             → C2: Snapshot of all files being renamed
About to run generator                 → C3: Generator inputs snapshot
Received new files from Tom            → C4: ZIP intake snapshot

CHECKPOINT NAMING CHEAT SHEET:
  {COUNT}_{TYPES}_{CATEGORY}_{DESCRIPTION}_{DATE}.zip
  Example: 11_TXT_CANON_CHECKPOINT_ALL_PRODUCTION_5_13_26.zip

ROLLBACK CHEAT SHEET:
  Problem in current session   → Level 1 (SESSION_CHECKPOINT)
  Whole cycle is bad           → Level 2 (STABILIZATION_CHECKPOINT)
  SGC output is bad            → Level 3 (PRE_RUN_BASELINE)
  Live site is broken          → Level 4 (PRE_DEPLOYMENT_BACKUP) + Tom auth

================================================================================
END COLLABTUNES ZIP CHECKPOINT POLICY
================================================================================
