576 lines
18 KiB
PL/PgSQL
576 lines
18 KiB
PL/PgSQL
-- 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;
|