Remove emojis from all markdown docs, add consolidation plan

- Strip emojis from 47 markdown files across docs/, sql/, and root
- Add docs/DOCS_CONSOLIDATION_PLAN.md with plan to reduce 45 docs to 8
- Establish no-emoji rule for documentation going forward

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

docs/PHASE3_NETWORK_DEVICES_MIGRATION_PLAN.md

@@ -1,7 +1,7 @@
 # Phase 3: Network Devices Migration to machines Table
 
 **Date:** 2025-11-10
-**Status:** 📋 PLANNING
+**Status:**  PLANNING
 **Follows:** Phase 2 (PC Migration - Completed)
 
 ---
@@ -14,7 +14,7 @@ Consolidate all network infrastructure devices (servers, switches, cameras, acce
 
 ## Scope
 
-### ✅ Migrate INTO machines Table:
+###  Migrate INTO machines Table:
 - **Servers** → machinetypeid 30
 - **Switches** → machinetypeid 31
 - **Cameras** → machinetypeid 32
@@ -23,7 +23,7 @@ Consolidate all network infrastructure devices (servers, switches, cameras, acce
 - **Routers** → machinetypeid 35 (if exists)
 - **Firewalls** → machinetypeid 36 (if exists)
 
-### ❌ Keep SEPARATE:
+###  Keep SEPARATE:
 - **Printers** → Stay in `printers` table (unique fields, workflows, APIs)
 
 ---
@@ -38,12 +38,12 @@ Consolidate all network infrastructure devices (servers, switches, cameras, acce
 5. **Inconsistent UI/UX:** Different interfaces for similar devices
 
 ### After Migration:
-1. ✅ **Single Source of Truth:** All infrastructure in `machines` table
-2. ✅ **Unified Relationships:** Camera → Switch → IDF using `machinerelationships`
-3. ✅ **Unified Communications:** All IPs in `communications` table
-4. ✅ **Consistent UI:** One set of pages for all devices
-5. ✅ **Powerful Queries:** Cross-device reports and topology mapping
-6. ✅ **Better Compliance:** All devices tracked in one place
+1.  **Single Source of Truth:** All infrastructure in `machines` table
+2.  **Unified Relationships:** Camera → Switch → IDF using `machinerelationships`
+3.  **Unified Communications:** All IPs in `communications` table
+4.  **Consistent UI:** One set of pages for all devices
+5.  **Powerful Queries:** Cross-device reports and topology mapping
+6.  **Better Compliance:** All devices tracked in one place
 
 ---
 
@@ -233,10 +233,10 @@ INSERT INTO relationshiptypes (relationshiptype, description, isbidirectional) V
 ## Migration Order
 
 ### Pre-Migration:
-1. ✅ **Backup database**
-2. ✅ **Verify Phase 2 is stable**
-3. ✅ **Document current table structures**
-4. ✅ **Count records in each table**
+1.  **Backup database**
+2.  **Verify Phase 2 is stable**
+3.  **Document current table structures**
+4.  **Count records in each table**
 
 ### Migration Steps:
 1. **Create new machinetypes** (30-36)
@@ -263,16 +263,16 @@ INSERT INTO relationshiptypes (relationshiptype, description, isbidirectional) V
 ## Code Updates Required
 
 ### Pages to Update:
-1. ✅ **displaymachines.asp** - Add filter tabs for network devices
-2. ✅ **displaymachine.asp** - Already supports all types via machinetypeid
-3. ✅ **machine_edit.asp** - Already supports all types
-4. ✅ **adddevice.asp** - Update to include network device types
+1.  **displaymachines.asp** - Add filter tabs for network devices
+2.  **displaymachine.asp** - Already supports all types via machinetypeid
+3.  **machine_edit.asp** - Already supports all types
+4.  **adddevice.asp** - Update to include network device types
 
 ### Pages to Deprecate:
-1. ❌ **displayservers.asp** → Redirect to displaymachines.asp?type=server
-2. ❌ **displayswitches.asp** → Redirect to displaymachines.asp?type=switch
-3. ❌ **displaycameras.asp** → Redirect to displaymachines.asp?type=camera
-4. ❌ **network_devices.asp** → Redirect to displaymachines.asp?category=network
+1.  **displayservers.asp** → Redirect to displaymachines.asp?type=server
+2.  **displayswitches.asp** → Redirect to displaymachines.asp?type=switch
+3.  **displaycameras.asp** → Redirect to displaymachines.asp?type=camera
+4.  **network_devices.asp** → Redirect to displaymachines.asp?category=network
 
 ### Views to Update:
 ```sql
@@ -389,7 +389,7 @@ SELECT COUNT(*) FROM cameras;
 
 ## Success Criteria
 
-### ✅ Migration Successful If:
+###  Migration Successful If:
 1. All records migrated (counts match)
 2. All IP addresses migrated to communications
 3. All relationships preserved
@@ -417,55 +417,55 @@ SELECT COUNT(*) FROM cameras;
 ## Risk Assessment
 
 ### Low Risk:
-- ✅ Pattern proven with Phase 2 PC migration
-- ✅ Can be rolled back easily
-- ✅ Old tables kept temporarily
-- ✅ Comprehensive verification
+-  Pattern proven with Phase 2 PC migration
+-  Can be rolled back easily
+-  Old tables kept temporarily
+-  Comprehensive verification
 
 ### Medium Risk:
-- ⚠️ Multiple tables being migrated
-- ⚠️ Code references to update
-- ⚠️ Testing required for all device types
+-  Multiple tables being migrated
+-  Code references to update
+-  Testing required for all device types
 
 ### Mitigation:
-- ✅ **Test on backup database first**
-- ✅ **Migrate one device type at a time**
-- ✅ **Verify after each migration**
-- ✅ **Keep old tables for 30 days**
-- ✅ **Update code incrementally**
+-  **Test on backup database first**
+-  **Migrate one device type at a time**
+-  **Verify after each migration**
+-  **Keep old tables for 30 days**
+-  **Update code incrementally**
 
 ---
 
 ## Benefits After Completion
 
 ### Immediate:
-1. ✅ Single query for all infrastructure
-2. ✅ Unified relationship management
-3. ✅ Camera → IDF relationships work
-4. ✅ Consistent UI across all devices
-5. ✅ Better network topology visibility
+1.  Single query for all infrastructure
+2.  Unified relationship management
+3.  Camera → IDF relationships work
+4.  Consistent UI across all devices
+5.  Better network topology visibility
 
 ### Long-Term:
-1. ✅ Easier to add new device types
-2. ✅ Less code duplication
-3. ✅ Better reporting capabilities
-4. ✅ Simplified maintenance
-5. ✅ CMDB-style asset management
-6. ✅ Better compliance tracking
+1.  Easier to add new device types
+2.  Less code duplication
+3.  Better reporting capabilities
+4.  Simplified maintenance
+5.  CMDB-style asset management
+6.  Better compliance tracking
 
 ---
 
 ## Next Steps
 
-1. ✅ **Create migration SQL scripts**
-2. ✅ **Create verification scripts**
-3. ✅ **Create rollback scripts**
-4. ✅ **Test on backup database**
-5. ✅ **Review and approve plan**
-6. ✅ **Schedule migration window**
-7. ✅ **Execute migration**
-8. ✅ **Update code**
-9. ✅ **Monitor and verify**
+1.  **Create migration SQL scripts**
+2.  **Create verification scripts**
+3.  **Create rollback scripts**
+4.  **Test on backup database**
+5.  **Review and approve plan**
+6.  **Schedule migration window**
+7.  **Execute migration**
+8.  **Update code**
+9.  **Monitor and verify**
 
 ---
 
@@ -478,11 +478,11 @@ SELECT COUNT(*) FROM cameras;
 
 ## Questions to Answer Before Migration
 
-1. ✅ Do accesspoints and idfs tables exist?
-2. ✅ Are there any custom fields in device tables we need to preserve?
-3. ✅ Are there any foreign key constraints to old tables?
-4. ✅ What's the maintenance window schedule?
-5. ✅ Should we create camera → IDF relationships during migration or manually after?
+1.  Do accesspoints and idfs tables exist?
+2.  Are there any custom fields in device tables we need to preserve?
+3.  Are there any foreign key constraints to old tables?
+4.  What's the maintenance window schedule?
+5.  Should we create camera → IDF relationships during migration or manually after?
 
 ---