firefrost-operations-manual/docs/core/revision-control-standard.md

# 📐 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** 💙🔥❄️