-- 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;
