diff --git a/docs/core/revision-control-standard.md b/docs/core/revision-control-standard.md new file mode 100644 index 0000000..79e8cb7 --- /dev/null +++ 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** 💙🔥❄️