Task #163: backfill script for empty task descriptions (6/15 matched)
This commit is contained in:
Claude Code
153
scripts/backfill-task-descriptions.js
Normal file
153
scripts/backfill-task-descriptions.js
Normal file
@@ -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();
|
||||
30
scripts/out/backfill-task-descriptions-report.md
Normal file
30
scripts/out/backfill-task-descriptions-report.md
Normal file
@@ -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 |
|
||||
575
scripts/out/backfill-task-descriptions.sql
Normal file
575
scripts/out/backfill-task-descriptions.sql
Normal file
@@ -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;
|
||||
Reference in New Issue
Block a user