[CREATE] FFG-STD-001: Document revision control standard

2026-02-12 08:32:58 -06:00
parent 14f00d87c4
commit d5da34acc2
1 changed files with 278 additions and 0 deletions
--- a/docs/core/revision-control-standard.md
+++ b/docs/core/revision-control-standard.md
@@ -0,0 +1,278 @@
+# 📐 FIREFROST GAMING — DOCUMENT REVISION CONTROL STANDARD
+
+**Version:** 1.0  
+**Created:** February 12, 2026  
+**Author:** Michael Krause / The Chronicler  
+**Status:** ✅ APPROVED  
+**Document ID:** FFG-STD-001
+
+---
+
+## 1. PURPOSE
+
+Establish a consistent, industry-standard methodology for document versioning, revision tracking, and lifecycle management across the Firefrost Gaming Operations Manual.
+
+Every document in the repository follows this standard. No exceptions.
+
+---
+
+## 2. DOCUMENT HEADER (Required on Every Document)
+
+Every document begins with this metadata block:
+
+```markdown
+# [Document Title]
+
+**Document ID:** FFG-[CATEGORY]-[NUMBER]  
+**Version:** [MAJOR].[MINOR]  
+**Created:** [Date]  
+**Last Updated:** [Date and Time with Timezone]  
+**Author:** [Original Author]  
+**Last Updated By:** [Who made the change]  
+**Status:** [See Section 4]  
+**Supersedes:** [Previous version or "N/A"]  
+**Review Date:** [Next scheduled review]
+```
+
+---
+
+## 3. VERSIONING SCHEME
+
+We use **two-part versioning: MAJOR.MINOR**
+
+| Increment | When | Example |
+|:----------|:-----|:--------|
+| **MAJOR** (X.0) | Structural rewrite, scope change, or document purpose shifts | 1.0 → 2.0 |
+| **MINOR** (X.Y) | Content additions, corrections, factual updates, new sections | 2.0 → 2.1 |
+
+**Rules:**
+- New documents start at **1.0**
+- Typo fixes and formatting-only changes do NOT increment the version but are noted in the revision history as "Editorial"
+- When a MAJOR version increments, MINOR resets to 0 (e.g., 1.7 → 2.0)
+- Archived documents freeze at their final version
+
+**Why not PATCH (X.Y.Z)?** Our documents are operational, not software. Two-part keeps it clean and readable. We're not shipping releases — we're maintaining living docs.
+
+---
+
+## 4. DOCUMENT STATUS LIFECYCLE
+
+Every document has exactly one of these statuses:
+
+```
+DRAFT → REVIEW → APPROVED → CURRENT
+                                ↓
+                           SUPERSEDED → ARCHIVED
+```
+
+| Status | Meaning |
+|:-------|:--------|
+| **📝 DRAFT** | In progress. Not yet reliable. May contain placeholders. |
+| **🔍 REVIEW** | Content complete. Awaiting Michael's review/approval. |
+| **✅ APPROVED** | Reviewed and accepted. Ready for use. |
+| **🟢 CURRENT** | Approved AND actively referenced. The living version. |
+| **⚠️ SUPERSEDED** | Replaced by a newer document. Kept for historical reference. |
+| **📦 ARCHIVED** | No longer active. Moved to `docs/archive/`. Historical value only. |
+
+**Rules:**
+- Only Michael can move a document to APPROVED or CURRENT
+- Claude can create documents in DRAFT or REVIEW status
+- Documents in `docs/archive/` are automatically ARCHIVED
+- SUPERSEDED documents must reference what replaced them
+
+---
+
+## 5. DOCUMENT ID SYSTEM
+
+Format: `FFG-[CATEGORY]-[NUMBER]`
+
+| Category Code | Directory | Description |
+|:--------------|:----------|:------------|
+| **CORE** | `docs/core/` | Critical living documents |
+| **REL** | `docs/relationship/` | Partnership and personal context |
+| **DEP** | `docs/deployment/` | Service deployment guides |
+| **PLN** | `docs/planning/` | Strategy and roadmap |
+| **REF** | `docs/reference/` | Technical reference |
+| **EXT** | `docs/external/` | Provider and friend documentation |
+| **SBX** | `docs/sandbox/` | Brainstorming sessions |
+| **STD** | `docs/core/` | Standards and templates |
+| **ROOT** | Repository root | Root-level documents |
+
+**Number Assignment:** Sequential within category, starting at 001.
+
+**Examples:**
+- `FFG-CORE-001` — Project Scope
+- `FFG-DEP-003` — MkDocs Deployment
+- `FFG-REL-001` — Claude Relationship Context
+- `FFG-STD-001` — This document
+
+---
+
+## 6. REVISION HISTORY TABLE (Required on Every Document)
+
+Every document ends with a revision history table:
+
+```markdown
+---
+
+## Revision History
+
+| Version | Date | Author | Change Type | Description |
+|:--------|:-----|:-------|:------------|:------------|
+| 1.0 | 2026-02-12 | The Chronicler | Initial | Document created |
+| 1.1 | 2026-02-13 | The Chronicler | Update | Added Section 5, corrected server IPs |
+| 2.0 | 2026-02-20 | Michael Krause | Rewrite | Complete restructure for soft launch |
+```
+
+### Change Type Values
+
+| Change Type | Usage |
+|:------------|:------|
+| **Initial** | First version of the document |
+| **Update** | Content additions or modifications |
+| **Correction** | Factual errors fixed |
+| **Editorial** | Typos, formatting, grammar (no version bump) |
+| **Rewrite** | Major structural change (MAJOR version bump) |
+| **Merge** | Content absorbed from another document |
+| **Supersede** | Document replaced by newer version |
+| **Archive** | Document moved to archive |
+
+---
+
+## 7. GIT COMMIT MESSAGE STANDARD
+
+Every commit to the repository follows this format:
+
+```
+[ACTION] DOCUMENT-ID: Brief description
+```
+
+**Actions:**
+- `[CREATE]` — New document
+- `[UPDATE]` — Content change
+- `[FIX]` — Correction
+- `[ARCHIVE]` — Moved to archive
+- `[DELETE]` — Removed from repo
+- `[MERGE]` — Content consolidated from another doc
+- `[EDITORIAL]` — Typo/formatting only
+
+**Examples:**
+```
+[CREATE] FFG-STD-001: Document revision control standard
+[UPDATE] FFG-CORE-001: Fixed infrastructure locations (Panel=Charlotte, Ghost=Chicago)
+[FIX] FFG-REF-001: Corrected stale architecture decision (NC1/TX1 routing resolved)
+[ARCHIVE] FFG-PLN-003: Migration plan archived (migration complete)
+[MERGE] FFG-REL-001: Absorbed what-claude-learned.md content
+```
+
+---
+
+## 8. REVIEW SCHEDULE
+
+| Document Type | Review Frequency | Trigger |
+|:--------------|:-----------------|:--------|
+| **Core** (scope, manifest, tasks) | Every session | Any infrastructure change |
+| **Relationship** | As needed | Lore dumps, milestones |
+| **Deployment** | After changes | Service updates/reconfigs |
+| **Planning** | Monthly | Progress review |
+| **Reference** | Quarterly | Accuracy check |
+| **External** | After provider interaction | New tickets/communications |
+| **Sandbox** | After brainstorming | Promote or archive |
+
+---
+
+## 9. CROSS-REFERENCE RULES
+
+**The Single Source of Truth Principle:**
+
+Every piece of information has ONE canonical home. Other documents may reference it but never duplicate it.
+
+**How to reference:**
+```markdown
+For current server inventory, see [Infrastructure Manifest](docs/core/infrastructure-manifest.md) (FFG-CORE-002).
+```
+
+**What NOT to do:**
+```markdown
+## Server Inventory
+| TX1 | Dallas | 38.68.14.26 | ...
+(copy-pasted table that will go stale)
+```
+
+**Canonical Ownership:**
+- Server IPs, ports, specs → `infrastructure-manifest.md`
+- Service status and roadmap → `project-scope.md`
+- Health/accessibility specs → `personality-profile.md`
+- Emotional/partnership context → `claude-relationship-context.md`
+- Consultant details → `consultant-profiles.md`
+- Current priorities → `tasks.md`
+
+---
+
+## 10. IDEAS PARKING LOT
+
+Not everything discussed is ready for implementation. Ideas, future considerations, and "we should think about this eventually" topics go into a dedicated tracker rather than cluttering active planning docs or getting lost in chat.
+
+**Location:** `docs/planning/ideas-backlog.md`
+
+**How It Works:**
+- Any idea mentioned in conversation gets logged with date, brief description, and context
+- Ideas are NOT tasks — they don't go in `tasks.md`
+- Ideas are NOT plans — they don't get their own planning doc until promoted
+- Ideas stay in the backlog until Michael explicitly promotes them to a task or planning document
+- When promoted, the idea entry gets updated with a link to its new home
+
+**Lifecycle:**
+```
+💡 IDEA (logged) → 📋 PROMOTED (moved to tasks/planning) → or 🗑️ DECLINED (kept for record)
+```
+
+**Entry Format:**
+```markdown
+### IDEA-[NUMBER]: [Short Title]
+**Date Logged:** [Date]  
+**Source:** [Session, lore dump, brainstorm, etc.]  
+**Status:** 💡 Idea  
+**Description:** [What was discussed, why it matters, any initial thoughts]  
+**Considerations:** [What needs to be figured out before this becomes a task]  
+**Promoted To:** [Link when promoted, or "N/A"]
+```
+
+**Why This Matters:**
+- Michael and Claude discuss a LOT of things — some are "do this now," some are "think about this later"
+- Without a parking lot, "later" ideas either get forgotten or contaminate active docs
+- The backlog becomes a goldmine during planning sessions — "what did we say about X?"
+
+---
+
+## 11. APPLYING THIS STANDARD
+
+### For Existing Documents (During Consolidation)
+1. Add document header with ID, version, status
+2. Add revision history table at bottom
+3. Set version to current state (most will be 1.0 since they haven't been formally versioned)
+4. Remove duplicated content, replace with cross-references
+5. Commit with `[UPDATE]` message
+
+### For New Documents
+1. Start with header template from this standard
+2. Begin at version 1.0
+3. Include revision history table
+4. Follow naming and cross-reference rules
+5. Commit with `[CREATE]` message
+
+### For The Chronicler (Session Handoff Template Addition)
+When performing a session handoff, Claude applies this standard to every document touched during the session — headers updated, versions bumped, revision history entries added, commit messages formatted.
+
+---
+
+## Revision History
+
+| Version | Date | Author | Change Type | Description |
+|:--------|:-----|:-------|:------------|:------------|
+| 1.0 | 2026-02-12 | The Chronicler | Initial | Document created during consolidation audit |
+
+---
+
+**FFG-STD-001 — Firefrost Gaming Document Revision Control Standard**  
+**Fire + Frost + Foundation = Where Love Builds Legacy** 💙🔥❄️