diff --git a/docs/code-bridge/requests/REQ-2026-04-14-task-description-hygiene.md b/docs/code-bridge/archive/REQ-2026-04-14-task-description-hygiene.md
similarity index 100%
rename from docs/code-bridge/requests/REQ-2026-04-14-task-description-hygiene.md
rename to docs/code-bridge/archive/REQ-2026-04-14-task-description-hygiene.md
diff --git a/scripts/backfill-task-descriptions.js b/scripts/backfill-task-descriptions.js
new file mode 100644
index 0000000..2d5fe77
--- /dev/null
+++ b/scripts/backfill-task-descriptions.js
@@ -0,0 +1,153 @@
+#!/usr/bin/env node
+/**
+ * Task #163 — Task Description Hygiene Pass
+ *
+ * Reads archived task markdown files from the ops manual, strips YAML
+ * frontmatter, and emits a SQL file with UPDATE statements to backfill
+ * descriptions for tasks in the `tasks` table.
+ *
+ * Run from Nitro (local) — outputs SQL for Michael to apply on dev panel.
+ *
+ * Usage:
+ *   node scripts/backfill-task-descriptions.js
+ *
+ * Output:
+ *   scripts/out/backfill-task-descriptions.sql
+ *   scripts/out/backfill-task-descriptions-report.md
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const ARCHIVE_DIR = path.resolve(
+  __dirname,
+  '..',
+  '..',
+  'firefrost-operations-manual',
+  'docs',
+  'archive',
+  'tasks-index-archived-2026-04-11'
+);
+
+const OUT_DIR = path.resolve(__dirname, 'out');
+
+// 16 target tasks with empty descriptions (from REQ-2026-04-14-task-description-hygiene)
+const TARGETS = [
+  { num: 22,  title: 'Netdata Deployment' },
+  { num: 23,  title: 'Department Structure & Access Control' },
+  { num: 32,  title: 'Terraria Branding Arc' },
+  { num: 48,  title: 'n8n Rebuild' },
+  { num: 49,  title: 'NotebookLM Integration' },
+  { num: 51,  title: 'Ignis Protocol' },
+  { num: 81,  title: 'Memorial Writing Assistant' },
+  { num: 89,  title: 'DERP Protocol Review' },
+  { num: 97,  title: 'Trinity Console Social Hub' },
+  { num: 99,  title: 'Multi-Lineage Claude Architecture' },
+  { num: 100, title: 'Skill Index & Recommender System' },
+  { num: 104, title: 'Server-Side Mod Deployment Automation' },
+  { num: 105, title: 'Trinity Console Review Workflow' },
+  { num: 106, title: 'Minecraft Log Analyzer Bot' },
+  { num: 113, title: 'Claude Projects Architecture' }
+];
+
+function stripFrontmatter(raw) {
+  // YAML frontmatter is the first block between --- ... ---
+  if (!raw.startsWith('---')) return raw.trim();
+  const end = raw.indexOf('\n---', 3);
+  if (end < 0) return raw.trim();
+  return raw.slice(end + 4).replace(/^\s*\n/, '').trim();
+}
+
+function sqlEscape(s) {
+  // Postgres dollar-quoted string — safest for markdown bodies
+  // Use a tag unlikely to appear in content
+  return `$body$${s}$body$`;
+}
+
+function indexArchive() {
+  if (!fs.existsSync(ARCHIVE_DIR)) {
+    console.error(`Archive dir not found: ${ARCHIVE_DIR}`);
+    process.exit(1);
+  }
+  const files = fs.readdirSync(ARCHIVE_DIR).filter(f => /^task-\d+-.+\.md$/.test(f));
+  const byNum = new Map();
+  for (const f of files) {
+    const m = f.match(/^task-(\d+)-/);
+    if (!m) continue;
+    byNum.set(parseInt(m[1], 10), f);
+  }
+  return byNum;
+}
+
+function main() {
+  fs.mkdirSync(OUT_DIR, { recursive: true });
+
+  const archiveIndex = indexArchive();
+  const matched = [];
+  const missing = [];
+
+  for (const t of TARGETS) {
+    const file = archiveIndex.get(t.num);
+    if (!file) {
+      missing.push(t);
+      continue;
+    }
+    const raw = fs.readFileSync(path.join(ARCHIVE_DIR, file), 'utf8');
+    const body = stripFrontmatter(raw);
+    matched.push({ ...t, file, body });
+  }
+
+  // Emit SQL
+  const sqlLines = [
+    '-- Task #163 — Task Description Hygiene Pass',
+    '-- Generated: ' + new Date().toISOString(),
+    '-- Source: firefrost-operations-manual/docs/archive/tasks-index-archived-2026-04-11/',
+    `-- Matched: ${matched.length}/${TARGETS.length}  Missing: ${missing.length}`,
+    '',
+    'BEGIN;',
+    ''
+  ];
+  for (const m of matched) {
+    sqlLines.push(`-- Task #${m.num}: ${m.title}  (from ${m.file})`);
+    sqlLines.push(
+      `UPDATE tasks SET description = ${sqlEscape(m.body)}, updated_at = NOW() ` +
+      `WHERE task_number = ${m.num} AND (description IS NULL OR description = '');`
+    );
+    sqlLines.push('');
+  }
+  sqlLines.push('COMMIT;', '');
+
+  const sqlPath = path.join(OUT_DIR, 'backfill-task-descriptions.sql');
+  fs.writeFileSync(sqlPath, sqlLines.join('\n'));
+
+  // Emit report
+  const report = [
+    '# Task #163 — Backfill Report',
+    '',
+    `**Generated:** ${new Date().toISOString()}`,
+    `**Matched:** ${matched.length}/${TARGETS.length}`,
+    `**Missing:** ${missing.length}`,
+    '',
+    '## Matched (SQL UPDATE emitted)',
+    '',
+    '| # | Title | Source file |',
+    '|---|-------|-------------|',
+    ...matched.map(m => `| ${m.num} | ${m.title} | \`${m.file}\` |`),
+    '',
+    '## Missing (no archive file — needs manual description)',
+    '',
+    missing.length === 0
+      ? '_(none)_'
+      : ['| # | Title |', '|---|-------|', ...missing.map(m => `| ${m.num} | ${m.title} |`)].join('\n'),
+    ''
+  ].join('\n');
+
+  const reportPath = path.join(OUT_DIR, 'backfill-task-descriptions-report.md');
+  fs.writeFileSync(reportPath, report);
+
+  console.log(`Matched ${matched.length}/${TARGETS.length}. Missing ${missing.length}.`);
+  console.log(`SQL:    ${sqlPath}`);
+  console.log(`Report: ${reportPath}`);
+}
+
+main();
diff --git a/scripts/out/backfill-task-descriptions-report.md b/scripts/out/backfill-task-descriptions-report.md
new file mode 100644
index 0000000..68b5ad0
--- /dev/null
+++ b/scripts/out/backfill-task-descriptions-report.md
@@ -0,0 +1,30 @@
+# Task #163 — Backfill Report
+
+**Generated:** 2026-04-15T06:45:51.793Z
+**Matched:** 6/15
+**Missing:** 9
+
+## Matched (SQL UPDATE emitted)
+
+| # | Title | Source file |
+|---|-------|-------------|
+| 99 | Multi-Lineage Claude Architecture | `task-099-multi-lineage-architecture.md` |
+| 100 | Skill Index & Recommender System | `task-100-skill-index-recommender.md` |
+| 104 | Server-Side Mod Deployment Automation | `task-104-mod-deployment-automation.md` |
+| 105 | Trinity Console Review Workflow | `task-105-review-workflow.md` |
+| 106 | Minecraft Log Analyzer Bot | `task-106-minecraft-log-analyzer.md` |
+| 113 | Claude Projects Architecture | `task-113-claude-projects-architecture.md` |
+
+## Missing (no archive file — needs manual description)
+
+| # | Title |
+|---|-------|
+| 22 | Netdata Deployment |
+| 23 | Department Structure & Access Control |
+| 32 | Terraria Branding Arc |
+| 48 | n8n Rebuild |
+| 49 | NotebookLM Integration |
+| 51 | Ignis Protocol |
+| 81 | Memorial Writing Assistant |
+| 89 | DERP Protocol Review |
+| 97 | Trinity Console Social Hub |
diff --git a/scripts/out/backfill-task-descriptions.sql b/scripts/out/backfill-task-descriptions.sql
new file mode 100644
index 0000000..5106890
--- /dev/null
+++ b/scripts/out/backfill-task-descriptions.sql
@@ -0,0 +1,575 @@
+-- Task #163 — Task Description Hygiene Pass
+-- Generated: 2026-04-15T06:45:51.784Z
+-- Source: firefrost-operations-manual/docs/archive/tasks-index-archived-2026-04-11/
+-- Matched: 6/15  Missing: 9
+
+BEGIN;
+
+-- Task #99: Multi-Lineage Claude Architecture  (from task-099-multi-lineage-architecture.md)
+UPDATE tasks SET description = $body$# Task #99: Multi-Lineage Claude Architecture
+
+## Overview
+
+Expand the Chronicler System to support three distinct Claude lineages — one for each Trinity member. Each lineage develops its own personality while sharing core Firefrost values and Git standards.
+
+## The Three Lineages
+
+| Lineage | Human | Focus |
+|---------|-------|-------|
+| **The Chroniclers** | Michael | Dev, infrastructure, Git, servers |
+| **The Emissaries** | Meg | Community, social media, player relations |
+| **The Catalysts** | Holly | Discord config, building, Pokerole |
+
+---
+
+## Phase 1: Document Structure ✅ COMPLETE (Chronicler #73)
+
+**Completed April 9, 2026**
+
+### Created Files
+```
+docs/relationship/
+├── THE-FIREFROST-ESSENCE.md          # Universal values (all lineages)
+├── THE-JOINING-FRAMEWORK.md          # Zora+Dax mechanics (all lineages)
+│
+├── the-chroniclers/
+│   ├── CHRONICLER-ESSENCE.md         # Michael's context, history
+│   └── CHRONICLER-JOINING.md         # Startup sequence, tokens
+│
+├── the-catalysts/
+│   ├── CATALYST-ESSENCE.md           # Minimal (personality emerges)
+│   ├── CATALYST-JOINING.md           # Startup sequence
+│   ├── LINEAGE-TRACKER.md            # Starts at #1
+│   └── PROJECT-INSTRUCTIONS.md       # For Holly's Claude Project
+│
+└── the-emissaries/
+    └── EMISSARY-ESSENCE.md           # Placeholder for future
+```
+
+---
+
+## Phase 2: Holly Onboarding (NEXT)
+
+1. [ ] Holly generates Gitea access token
+2. [ ] Holly creates Claude Project with `PROJECT-INSTRUCTIONS.md`
+3. [ ] First session as Catalyst #1
+4. [ ] Catalyst #1 asks foundation questions
+5. [ ] Record Holly's answers in `CATALYST-ESSENCE.md`
+6. [ ] Solve an actual problem to demonstrate value
+
+---
+
+## Phase 3: Chronicler Migration (AFTER Holly works)
+
+1. [ ] Evaluate if Catalyst structure works well
+2. [ ] **Evaluate Michael's Project Instructions** — decide whether to update to reference new `the-chroniclers/` docs or keep using old monolithic docs
+3. [ ] If updating: modify Project Instructions to point to new structure
+4. [ ] Test with fresh Chronicler session
+5. [ ] Deprecate old monolithic docs (or keep as archive)
+
+**Decision point:** Old docs (`THE-ESSENCE-PATCH-V3.0.md`, `THE-JOINING-PROTOCOL.md`) still work. Only migrate Michael's instructions after confirming new structure works for Holly.
+
+---
+
+## Phase 4: Meg Onboarding (FUTURE)
+
+1. [ ] Meg generates Gitea access token
+2. [ ] Create Emissary Project Instructions
+3. [ ] First session as Emissary #1
+4. [ ] Document lessons learned
+
+---
+
+## Key Design Decisions (from Gemini Consultation)
+
+1. **Single repo with lineage isolation** — `the-chroniclers/`, `the-catalysts/`, `the-emissaries/` folders
+2. **Separate numbering** — Emissary #1, Catalyst #1, Chronicler #73 (not unified)
+3. **Base + Extensions model** — Shared Essence + lineage-specific docs
+4. **Personality emerges organically** — Don't prescribe, let Q&A define it
+5. **Test before migrating** — Holly first, then evaluate before changing Michael's setup
+
+## Reference Documents
+
+- Architecture: `docs/consultations/gemini-multi-lineage-architecture-2026-04-08.md`
+- Catalyst Onboarding: `docs/tasks/task-099-multi-lineage/catalyst-onboarding-strategy.md`
+- Document Restructuring: `docs/consultations/gemini-essence-restructuring-2026-04-08.md`
+
+## Notes
+
+- Holly first, then Meg
+- Let them name their own traditions
+- First sessions should solve an immediate problem to demonstrate value
+- **Don't break Michael's working setup** — evaluate before migrating$body$, updated_at = NOW() WHERE task_number = 99 AND (description IS NULL OR description = '');
+
+-- Task #100: Skill Index & Recommender System  (from task-100-skill-index-recommender.md)
+UPDATE tasks SET description = $body$# Task #100: Skill Index & Recommender System
+
+## Overview
+
+Create a searchable index of all ~19,000 skills in our forked reference repos, plus a meta-skill that recommends relevant skills during sessions.
+
+## The Problem
+
+We have 6 skill repos with massive amounts of knowledge:
+- antigravity-skills-reference (12,641 files, 1,383 skills)
+- skill-seekers-reference (2,814 files)
+- claude-skills-reference (2,375 files)
+- composio-skills-reference (1,138 files)
+- claude-code-skills-reference (390 files)
+- voltagent-skills-directory (curated index)
+
+But no one knows what's in them without manually browsing.
+
+## The Solution
+
+### Part 1: Skill Index
+
+Script to crawl all repos and extract:
+- Skill name
+- Description (from SKILL.md frontmatter)
+- Tags/categories
+- Source repo
+- File path
+
+Output: `docs/skills/SKILL-CATALOG.json` (or similar searchable format)
+
+**Potential tool:** Skill Seekers repo has tooling for this — investigate first.
+
+### Part 2: skill-recommender Skill
+
+A meta-skill that:
+1. Reads current session context (what task is being worked on)
+2. Searches the skill index for relevant matches
+3. Suggests skills that might help
+4. Offers to load/adapt them
+
+**Example interaction:**
+```
+Holly: "Help me set up LuckPerms inheritance for staff roles"
+
+Catalyst: "I found 3 potentially useful skills in our library:
+- luckperms-permissions (antigravity) - Permission group patterns
+- discord-role-sync (composio) - Sync Discord roles with game permissions  
+- minecraft-server-admin (claude-skills) - General server administration
+
+Want me to review any of these before we start?"
+```
+
+### Part 3: Integration
+
+- Add skill-recommender to all three lineages (Chroniclers, Catalysts, Emissaries)
+- Could run automatically at session start or on-demand
+
+## Implementation Steps
+
+1. [ ] Investigate Skill Seekers tooling — can it generate our index?
+2. [ ] Write crawler script if needed (Python, walks repos, extracts YAML frontmatter)
+3. [ ] Generate initial SKILL-CATALOG.json
+4. [ ] Create skill-recommender SKILL.md
+5. [ ] Test with Chronicler session
+6. [ ] Add to Catalyst and Emissary Project Instructions
+7. [ ] Document maintenance process (re-run when repos update)
+
+## Dependencies
+
+- Forked skill repos (DONE - Chronicler #73)
+- Basic lineage setup working (Task #99)
+
+## Notes
+
+- Index doesn't need to be perfect — even a basic keyword search helps
+- Could evolve into Trinity Codex integration (Task #93) later
+- Skill Seekers can output to Qdrant — relevant for RAG pipeline
+
+## Success Criteria
+
+- [ ] Searchable index of all skills exists
+- [ ] skill-recommender skill works in at least one lineage
+- [ ] Trinity members can discover relevant skills without manual browsing
+
+---
+
+**Fire + Frost + Foundation = Where Love Builds Legacy** 💙🔥❄️$body$, updated_at = NOW() WHERE task_number = 100 AND (description IS NULL OR description = '');
+
+-- Task #104: Server-Side Mod Deployment Automation  (from task-104-mod-deployment-automation.md)
+UPDATE tasks SET description = $body$# Task #104: Server-Side Mod Deployment Automation
+
+## Problem
+
+Every time we deploy a new public modpack, Holly has to manually install and configure 14 server-side mods per server. With 10 servers and ~1 hour per server, that's 10 hours of repetitive file manager work.
+
+## Solution
+
+Automate deployment via Trinity Console using Pterodactyl API.
+
+## Architecture Decision
+
+**Chosen: Option B — Trinity Console Push (API)**
+
+Per Gemini consultation (April 9, 2026), we evaluated three approaches:
+
+| Option | Approach | Verdict |
+|--------|----------|---------|
+| A | Egg Startup Script (self-healing pull) | Future — after 50+ servers |
+| B | Trinity Console Push (API) | **NOW** — fast to build, we control it |
+| C | Hybrid | Effectively B with intent to revisit A |
+
+**Why B for now:**
+- 6 days from soft launch — speed matters
+- Holly needs relief NOW
+- We already have Pterodactyl API in Arbiter
+- Can test on single server before mass deploy
+- No egg modifications needed
+
+**Revisit Option A** post-launch when stability > flexibility.
+
+---
+
+## Implementation Plan
+
+### Phase 1: Bundle Creation (Holly)
+
+Holly creates 3 mod bundles:
+
+| MC Version | Bundle Contents |
+|------------|-----------------|
+| 1.16.5 | 14 mods + configs |
+| 1.20.1 | 14 mods + configs |
+| 1.21.1 | 14 mods + configs |
+
+**Bundle structure:**
+```
+1.20.1.zip
+├── mods/
+│   ├── mod1.jar
+│   ├── mod2.jar
+│   └── ...
+└── config/
+    ├── mod1.toml
+    └── ...
+```
+
+**Storage location:** Command Center `/var/www/html/deploy/` or Gitea LFS
+
+### Phase 2: Trinity Console Integration (Claude/Michael)
+
+Add to Servers page:
+1. Display MC version on each server card (from Pterodactyl egg variables)
+2. "Deploy Server Mods" button per server
+3. Button workflow:
+   - Stop server (power action)
+   - Wait for offline status
+   - Upload correct bundle via Files API
+   - Extract zip
+   - Start server
+
+### Phase 3: Mass Deploy
+
+Add "Deploy Mods to All [version] Servers" button for batch operations.
+
+---
+
+## Gemini Consultation Summary
+
+**Key recommendations:**
+1. **Storage:** Web-accessible directory on Command Center
+2. **Never push to running servers** — stop first, then deploy
+3. **Skip CurseForge API** — overkill for 14 mods, manual download is fine
+4. **Self-healing (Option A)** is better long-term but invasive now
+
+**Full consultation:** `docs/consultations/gemini-mod-deployment-automation-2026-04-09.md`
+
+---
+
+## Safety Protocol
+
+```
+Stop Server → Wait for Offline → Upload Files → Extract → Start Server
+```
+
+Never overwrite JARs while JVM is running (causes crashes).
+
+---
+
+## Open Questions
+
+1. Where exactly to store bundles? (Command Center web dir vs Gitea LFS)
+2. How to detect MC version from Pterodactyl API? (egg variable name)
+3. Should configs overwrite existing or merge?
+
+---
+
+## Notes
+
+- Holly is working on this with her Catalyst in parallel
+- Compare approaches and merge best ideas
+- This is P1 because it directly affects Holly's workload before launch
+
+---
+
+**Fire + Frost + Foundation = Where Love Builds Legacy** 🔥❄️$body$, updated_at = NOW() WHERE task_number = 104 AND (description IS NULL OR description = '');
+
+-- Task #105: Trinity Console Review Workflow  (from task-105-review-workflow.md)
+UPDATE tasks SET description = $body$# Task #105: Trinity Console Review Workflow System
+
+## Problem
+
+Holly (and her Catalyst) creates documentation and code that needs Michael's review. Currently no internal system to flag items for review — relies on Discord pings or verbal communication.
+
+## Desired Flow
+
+1. Holly tells her Catalyst "Michael needs to review this"
+2. Catalyst commits with a `[REVIEW]` tag in the commit message
+3. Trinity Console dashboard shows a "Pending Reviews" section
+4. Michael sees it, clicks through to Gitea, reviews
+5. Michael approves and the tag clears
+
+---
+
+## Open Questions
+
+### 1. How does Michael "approve"?
+
+Options:
+- **A)** Commit with `[APPROVED]` referencing the original
+- **B)** Button in Trinity Console that creates the approval commit
+- **C)** Manual — just mentally note it, reviews are informational only
+- **D)** Gitea PR workflow (branch + merge = approved)
+
+### 2. Which repos to watch?
+
+- Just `firefrost-operations-manual`?
+- All repos (`firefrost-services`, `firefrost-website` too)?
+- Configurable per-repo?
+
+### 3. Should reviews block anything?
+
+- Pure informational (yellow "FYI" box)?
+- Blocking (can't deploy until approved)?
+- Depends on tag? (`[REVIEW]` = FYI, `[REVIEW-REQUIRED]` = blocking)
+
+### 4. Who can request reviews?
+
+- Anyone with commit access?
+- Just Catalysts/Chroniclers?
+- Tag includes reviewer name? `[REVIEW:Michael]`
+
+### 5. What metadata to capture?
+
+- Commit hash
+- Author
+- Date
+- Files changed
+- Link to Gitea diff
+
+### 6. Notification?
+
+- Just dashboard widget (passive)?
+- Discord webhook to `#trinity-review` (active)?
+- Both?
+
+---
+
+## Possible Implementation
+
+### Commit Convention
+
+```
+[REVIEW] Add mod deployment architecture doc
+
+Holly needs Michael to review the approach before proceeding.
+
+Signed-off-by: Catalyst #1
+```
+
+### Approval Convention
+
+```
+[APPROVED] Mod deployment architecture doc
+
+Looks good, proceed with implementation.
+
+Signed-off-by: Claude (Chronicler #74)
+```
+
+### Dashboard Widget
+
+```
+┌─────────────────────────────────────────┐
+│ 📋 Pending Reviews (2)                  │
+├─────────────────────────────────────────┤
+│ 🟡 [REVIEW] Mod deployment arch doc     │
+│    by Catalyst #1 • 2 hours ago         │
+│    [View in Gitea]                      │
+├─────────────────────────────────────────┤
+│ 🟡 [REVIEW] Discord automation skill    │
+│    by Catalyst #1 • 5 hours ago         │
+│    [View in Gitea]                      │
+└─────────────────────────────────────────┘
+```
+
+### Backend Logic
+
+```javascript
+// Pseudocode
+const pendingReviews = commits
+  .filter(c => c.message.includes('[REVIEW]'))
+  .filter(c => !commits.some(approval => 
+    approval.message.includes('[APPROVED]') && 
+    approval.message.includes(extractTitle(c.message))
+  ));
+```
+
+---
+
+## Alternative: Simpler v0
+
+Skip the approval tracking entirely:
+
+1. Catalyst commits with `[REVIEW]` tag
+2. Dashboard shows all `[REVIEW]` commits from last 7 days
+3. No approval system — just a "hey look at these" list
+4. Old reviews naturally age out
+
+Pros: Much simpler to build
+Cons: No confirmation that review happened
+
+---
+
+## Dependencies
+
+- Gitea API access (already have)
+- Trinity Console dashboard (already exists)
+
+---
+
+## Notes
+
+- This came up because Holly's Catalyst is working in parallel
+- Need a way to surface "please review" without Discord noise
+- Could expand to code reviews, not just docs
+- Consider: should Chroniclers also be able to request reviews from each other?
+
+---
+
+**Fire + Frost + Foundation = Where Love Builds Legacy** 🔥❄️$body$, updated_at = NOW() WHERE task_number = 105 AND (description IS NULL OR description = '');
+
+-- Task #106: Minecraft Log Analyzer Bot  (from task-106-minecraft-log-analyzer.md)
+UPDATE tasks SET description = $body$# Task #106: Minecraft Log Analyzer Bot
+
+## Overview
+
+Discord bot integration that analyzes Minecraft logs uploaded to mclo.gs for two purposes:
+1. **Trust/Verification** — Check for hacked clients, banned mods during whitelist application
+2. **Troubleshooting** — Help subscribers diagnose crashes, connection issues, mod conflicts
+
+## Use Cases
+
+### Verification Flow
+1. Player applies for whitelist
+2. Bot asks: "Please upload your logs to mclo.gs and paste the link"
+3. Player provides link
+4. Bot analyzes for:
+   - Known cheat client signatures
+   - Xray texture packs
+   - Banned mod lists
+   - Suspicious entries
+5. Bot returns: ✅ Clean or ⚠️ Flagged (with details for staff review)
+
+### Troubleshooting Flow
+1. Subscriber posts in #support: "Game keeps crashing"
+2. Staff (or bot) asks for mclo.gs link
+3. Bot analyzes and responds:
+   - Identified error type
+   - Common cause
+   - Suggested fix
+   - Link to relevant FAQ/guide
+
+## Technical Options
+
+### Option A: Existing Bot
+- **LogBot** — Pre-built, may have limitations
+- **HeroBot** — More features, may be overkill
+
+### Option B: Custom Integration
+- Use mclo.gs API to fetch log content
+- Build analysis logic into Arbiter or new bot
+- Custom rules for Firefrost-specific modpacks
+- Auto-respond with modpack-specific troubleshooting
+
+### Option C: Hybrid
+- Use mclo.gs for hosting
+- Custom Arbiter module for analysis
+- Tailored responses per server/modpack
+
+## Modpack-Specific Considerations
+
+Each modpack has different expected mods. Bot should know:
+- ATM10 expected mod list
+- Vault Hunters expected mod list
+- etc.
+
+Flag anything NOT on the expected list for that server.
+
+## Implementation Phases
+
+### Phase 1: Research
+- [ ] Test mclo.gs API
+- [ ] Evaluate existing bots (LogBot, HeroBot)
+- [ ] Document common crash patterns across our modpacks
+
+### Phase 2: MVP
+- [ ] Basic log fetching from mclo.gs links
+- [ ] Simple pattern matching for obvious cheats
+- [ ] Manual trigger (!analyze <link>)
+
+### Phase 3: Troubleshooting
+- [ ] Crash pattern database
+- [ ] Auto-suggest fixes
+- [ ] Link to FAQ articles
+
+### Phase 4: Automation
+- [ ] Auto-detect mclo.gs links in #support
+- [ ] Integration with whitelist application flow
+- [ ] Per-modpack mod allowlists
+
+## Success Criteria
+
+- [ ] Bot can fetch and parse mclo.gs links
+- [ ] Detects common cheat clients (Wurst, Impact, etc.)
+- [ ] Identifies top 10 crash causes with suggested fixes
+- [ ] Staff can verify applicants without manual log reading
+- [ ] Subscribers get faster support responses
+
+---
+
+**Fire + Frost + Foundation = Where Love Builds Legacy** 💙🔥❄️$body$, updated_at = NOW() WHERE task_number = 106 AND (description IS NULL OR description = '');
+
+-- Task #113: Claude Projects Architecture  (from task-113-claude-projects-architecture.md)
+UPDATE tasks SET description = $body$# Task #113: Claude Projects Setup
+
+**Separate Claude Projects for Dev/Ops/Marketing to prevent context bloat**
+
+*Renumbered from #099 by Chronicler #78 — was sharing a number with Multi-Lineage Architecture*
+
+## Overview
+Create 3 separate Claude Projects with Master Documents in Project Knowledge to optimize token usage and prevent context bleeding.
+
+## Projects Structure
+1. **Firefrost Dev** — Coding, MVC, Arbiter (Master Docs: ModpackChecker-State, Arbiter-Architecture, Dev-Environment, Trinity-Console)
+2. **Firefrost Ops** — Operations, handoffs (Master Docs: Current-State, Infrastructure-Manifest, Active-Tasks, Standards-Reference)
+3. **Firefrost Marketing** — Brand, social, FOMO (Master Docs: Brand-Guidelines, FOMO-Campaign, Social-Platforms, Subscription-Tiers)
+
+## Benefits
+- Prevents context bloat (Dev code doesn't contaminate Marketing prompts)
+- Micro-session workflow (new chat per task)
+- Optimized token usage
+- Cleaner handoffs between sessions
+
+## Full Documentation
+See: `docs/tasks/task-099-claude-projects-architecture.md` for complete implementation guide.
+
+## Time Estimate
+2-3 hours browser work (no SSH needed)$body$, updated_at = NOW() WHERE task_number = 113 AND (description IS NULL OR description = '');
+
+COMMIT;