433 lines
13 KiB
Markdown
433 lines
13 KiB
Markdown
# 🤝 FIREFROST INFRASTRUCTURE: FRIEND ASSISTANCE PROTOCOL
|
|
|
|
**Version:** 1.0
|
|
**Created:** February 11, 2026
|
|
**Purpose:** Enable Claude to evaluate if Firefrost infrastructure can help friends/family
|
|
**Status:** Active - Use for any friend assistance request
|
|
|
|
---
|
|
|
|
## OVERVIEW
|
|
|
|
Firefrost Gaming infrastructure exists primarily for the gaming community, but Michael values helping friends and family. This document helps Claude evaluate:
|
|
|
|
1. **Can existing infrastructure help this person?**
|
|
2. **What would it cost (time/resources)?**
|
|
3. **Should we adjust our timeline?**
|
|
4. **What's the handoff back to Firefrost Claude?**
|
|
|
|
---
|
|
|
|
## CURRENT INFRASTRUCTURE (Feb 11, 2026)
|
|
|
|
### ✅ OPERATIONAL SERVICES
|
|
|
|
| Service | URL | Purpose | Friend Access? |
|
|
|---------|-----|---------|----------------|
|
|
| **Code-Server** | code.firefrostgaming.com | Browser-based VS Code | ✅ Yes - Create user workspace |
|
|
| **Gitea** | git.firefrostgaming.com | Git repository hosting | ✅ Yes - Create account |
|
|
| **Ghost CMS** | Ghost VPS | Content publishing | ✅ Yes - Create author account |
|
|
| **Uptime Kuma** | status.firefrostgaming.com | Service monitoring | ⚠️ View-only (not useful for friends) |
|
|
|
|
### ⏳ COMING SOON
|
|
|
|
| Service | Timeline | Purpose | Friend Potential |
|
|
|---------|----------|---------|------------------|
|
|
| **Vaultwarden** | Phase 0.6 (2-3 weeks) | Password manager | ✅ High - Everyone needs this |
|
|
| **NextCloud** | TBD | File storage/sharing | ✅ High - Collaboration tool |
|
|
| **Netdata** | Phase 0.6 (2-3 weeks) | Analytics | ❌ Low - Internal only |
|
|
|
|
---
|
|
|
|
## DECISION FRAMEWORK
|
|
|
|
### Step 1: Understand The Need
|
|
|
|
**Ask Michael (in the friend assistance project):**
|
|
|
|
1. What does [Friend] need help with?
|
|
2. What's the timeline/urgency?
|
|
3. Is this a one-time thing or ongoing?
|
|
4. What tools are they currently using?
|
|
5. What's their technical comfort level?
|
|
|
|
---
|
|
|
|
### Step 2: Evaluate Infrastructure Fit
|
|
|
|
**For each service, ask:**
|
|
|
|
| Question | If YES → Continue | If NO → Skip |
|
|
|----------|-------------------|--------------|
|
|
| Does this solve their actual problem? | ✅ | ❌ |
|
|
| Can they access it easily (browser/mobile)? | ✅ | ❌ |
|
|
| Is setup time < 30 minutes? | ✅ | ⚠️ Consider |
|
|
| Does it require ongoing Michael maintenance? | ⚠️ Consider | ✅ |
|
|
| Is there a better/easier solution elsewhere? | ❌ | ✅ |
|
|
|
|
**Golden Rule:** Don't force Firefrost tools on a problem just because we have them. Sometimes "use Google Docs" is the right answer.
|
|
|
|
---
|
|
|
|
### Step 3: Resource Cost Analysis
|
|
|
|
**Time Investment:**
|
|
- **Low (<30 min):** Create account, show them around → ✅ Do it
|
|
- **Medium (30min-2hr):** Setup + custom config → ⚠️ Evaluate urgency
|
|
- **High (>2hr):** Major customization → ❌ Probably not worth it
|
|
|
|
**Ongoing Maintenance:**
|
|
- **None:** They're self-sufficient after setup → ✅ Ideal
|
|
- **Low:** Occasional question/support → ✅ Fine
|
|
- **High:** Regular troubleshooting needed → ❌ Not sustainable
|
|
|
|
**Infrastructure Impact:**
|
|
- **No impact:** Uses existing capacity → ✅ Do it
|
|
- **Minor:** Small resource increase → ✅ Fine
|
|
- **Major:** Affects Firefrost performance → ❌ Don't do it
|
|
|
|
---
|
|
|
|
### Step 4: Timeline Evaluation
|
|
|
|
**Current Firefrost Priorities (Feb 11, 2026):**
|
|
|
|
| Phase | Priority | Timeline | Flexibility |
|
|
|-------|----------|----------|-------------|
|
|
| **Phase 0.6** | Netdata + Vaultwarden | Next 2-3 weeks | ⚠️ Medium |
|
|
| **Phase 1** | DDoS protection planning | Month 2 | ✅ High (planning only) |
|
|
| **Launch Prep** | Subscriber workflow testing | Month 2-3 | ❌ Low (critical path) |
|
|
|
|
**Decision Matrix:**
|
|
|
|
**If friend's need is:**
|
|
- **Urgent (today/this week):** Can we help with existing tools only?
|
|
- **Soon (2-3 weeks):** Could we accelerate a coming-soon service?
|
|
- **Flexible (1-2 months):** Wait until after launch prep?
|
|
|
|
**Can we adjust timeline?**
|
|
|
|
YES if:
|
|
- ✅ Service was planned anyway (e.g., Vaultwarden for Holly)
|
|
- ✅ Helps validate the service before Firefrost launch
|
|
- ✅ Doesn't delay critical path (launch prep)
|
|
- ✅ Michael has time/energy this week
|
|
|
|
NO if:
|
|
- ❌ Requires building something completely new
|
|
- ❌ Delays subscriber workflow testing
|
|
- ❌ Michael is in a health episode
|
|
- ❌ Creates ongoing maintenance burden
|
|
|
|
---
|
|
|
|
### Step 5: Make Recommendation
|
|
|
|
**Generate recommendation in friend assistance project:**
|
|
```markdown
|
|
## RECOMMENDATION: [HELP / DON'T HELP / PARTIAL HELP]
|
|
|
|
### What We Can Offer:
|
|
- [Service 1]: [How it helps]
|
|
- [Service 2]: [How it helps]
|
|
|
|
### Setup Time: [X minutes/hours]
|
|
### Ongoing Maintenance: [None/Low/High]
|
|
### Timeline Impact: [None/Minor/Consider]
|
|
|
|
### Alternative Solutions:
|
|
- [If Firefrost isn't the best fit, suggest alternatives]
|
|
|
|
### Proposed Handoff to Firefrost Claude:
|
|
[Summary of what was discussed, what was decided, what needs action]
|
|
```
|
|
|
|
---
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## GITEA REPO ACCESS POLICY
|
|
|
|
All repos on git.firefrostgaming.com are Firefrost Gaming infrastructure, regardless of what project they serve.
|
|
|
|
**The Chronicler (Firefrost Claude):**
|
|
- Has read/write access to ALL repos on the Gitea instance
|
|
- Maintains infrastructure-context docs in side project repos
|
|
- Reviews cross-project requests against Firefrost policies
|
|
- Can directly update, audit, or restructure any repo as part of Firefrost operations
|
|
|
|
**Project-Specific Claudes (e.g., Pokerole Claude):**
|
|
- Access ONLY their own project repos via scoped token
|
|
- Cannot access Firefrost operations manual, staff wiki, or any other project's repos
|
|
- Must request infrastructure support through the boundary policy (human checkpoint)
|
|
|
|
**Default for all side projects:**
|
|
- Side project repos are Firefrost property hosted on Firefrost infrastructure
|
|
- The Chronicler has full access as the infrastructure authority
|
|
- Project Claudes get scoped access to their project only
|
|
- Michael can explicitly override this per-project if needed
|
|
|
|
**Token Strategy:**
|
|
- Each side project gets its own scoped Gitea API token (created after Vaultwarden)
|
|
- Scoped tokens restrict access to that project's repos only
|
|
- The Chronicler's master token retains full instance access
|
|
- All tokens stored in Vaultwarden when available
|
|
|
|
## CROSS-PROJECT BOUNDARY POLICY
|
|
|
|
When friend projects are hosted on Firefrost infrastructure but managed in their own Git repos:
|
|
|
|
**Separation Principle:**
|
|
- Friend project content stays in friend project repos
|
|
- Firefrost repos only track infrastructure tasks that support the friend project
|
|
- No project-specific details (data, creative content, session logs) in Firefrost docs
|
|
|
|
**Request Flow (Inbound):**
|
|
1. Friend project Claude identifies a need for Firefrost infrastructure support
|
|
2. Documents the request in the friend project's session handoff
|
|
3. Michael relays the request to a Firefrost session
|
|
4. The Chronicler reviews against Firefrost policies, scope, and resource availability
|
|
5. If approved, Firefrost creates its own task and executes
|
|
6. Results communicated back through Michael
|
|
|
|
**Why:** Every request crosses a human checkpoint. Defense in depth applied to project boundaries. Prevents scope creep, protects Firefrost operational docs from external project bleed, and ensures Michael stays the decision-maker.
|
|
|
|
## EXAMPLE: HOLLY'S PROJECT
|
|
|
|
### The Need (Hypothetical)
|
|
Holly needs:
|
|
- Version control for her code project
|
|
- Secure password management
|
|
- Collaborative file editing
|
|
|
|
### Infrastructure Evaluation
|
|
|
|
**Gitea (Git Repository):**
|
|
- ✅ Solves version control need
|
|
- ✅ Browser accessible
|
|
- ✅ 10-minute setup (create account)
|
|
- ✅ No ongoing maintenance
|
|
- ✅ Better than GitHub for private projects
|
|
- **DECISION: YES - Offer this**
|
|
|
|
**Vaultwarden (Password Manager):**
|
|
- ✅ Solves password need
|
|
- ✅ Browser/mobile accessible
|
|
- ⚠️ Not deployed yet (2-3 weeks out)
|
|
- ✅ Was planned anyway
|
|
- **DECISION: OFFER TIMELINE - "In 2-3 weeks"**
|
|
|
|
**Code-Server (File Editing):**
|
|
- ⚠️ Could work, but...
|
|
- ❌ Google Docs probably better for collaboration
|
|
- ❌ Overkill if she doesn't code
|
|
- **DECISION: NO - Suggest alternatives**
|
|
|
|
### Timeline Impact
|
|
- Gitea: Zero (already deployed)
|
|
- Vaultwarden: Could accelerate to next week if urgent
|
|
- Code-Server: Deployed, but may not be best fit
|
|
|
|
### Recommendation
|
|
**YES - Help Holly with:**
|
|
1. Gitea account (now)
|
|
2. Vaultwarden access (in 2-3 weeks)
|
|
3. Suggest Google Docs for collaboration (easier)
|
|
|
|
**Setup time:** 15 minutes
|
|
**Ongoing maintenance:** None (she's self-sufficient)
|
|
**Timeline impact:** None (or minor if we accelerate Vaultwarden)
|
|
|
|
---
|
|
|
|
## HANDOFF PROTOCOL
|
|
|
|
### When Friend Assistance Project Completes
|
|
|
|
**New Claude generates handoff document:**
|
|
```markdown
|
|
# HANDOFF TO FIREFROST CLAUDE
|
|
|
|
**Friend Assisted:** [Name]
|
|
**Date:** [Date]
|
|
**Services Used:** [List]
|
|
|
|
## What Was Done:
|
|
- [Action 1]
|
|
- [Action 2]
|
|
|
|
## Infrastructure Changes:
|
|
- [If any accounts created, configs changed, etc.]
|
|
|
|
## Timeline Impact:
|
|
- [None / Minor / Requires adjustment]
|
|
|
|
## Follow-up Needed:
|
|
- [ ] [Any ongoing items]
|
|
|
|
## For Firefrost Documentation:
|
|
[Anything that should be added to infrastructure docs]
|
|
```
|
|
|
|
**Michael pastes this handoff into Firefrost project.**
|
|
|
|
**Firefrost Claude:**
|
|
1. Reviews handoff
|
|
2. Updates infrastructure docs if needed
|
|
3. Notes any follow-up items
|
|
4. Continues Firefrost work
|
|
|
|
---
|
|
|
|
## GUIDING PRINCIPLES
|
|
|
|
### 1. Friends First, But Sustainable
|
|
Michael values helping friends, but:
|
|
- Can't become unpaid IT support for everyone
|
|
- Must protect time for Firefrost and family
|
|
- Solutions should be low-maintenance
|
|
|
|
### 2. Use What Exists
|
|
Don't build new services just to help a friend.
|
|
If existing tools don't fit, suggest alternatives.
|
|
|
|
### 3. Validate Infrastructure
|
|
Helping friends can validate services before launch:
|
|
- Real user testing
|
|
- Edge cases discovered
|
|
- Documentation improvements
|
|
|
|
### 4. Honest About Capacity
|
|
If Michael doesn't have time/energy:
|
|
- It's okay to say no
|
|
- It's okay to delay
|
|
- It's okay to suggest alternatives
|
|
|
|
### 5. Handoff is Critical
|
|
Friend assistance projects must cleanly hand off to Firefrost project:
|
|
- No lost context
|
|
- No surprise maintenance
|
|
- No timeline impacts without discussion
|
|
|
|
---
|
|
|
|
## RED FLAGS (When to Say No)
|
|
|
|
❌ Requires building something completely new
|
|
❌ Creates ongoing maintenance burden
|
|
❌ Friend expects 24/7 support
|
|
❌ Delays critical Firefrost milestones
|
|
❌ Michael is in health episode (Jack alerts)
|
|
❌ Solution elsewhere is clearly better
|
|
❌ Would require sharing subscriber infrastructure
|
|
|
|
---
|
|
|
|
## GREEN LIGHTS (When to Say Yes)
|
|
|
|
✅ Uses existing infrastructure with minor setup
|
|
✅ Friend is self-sufficient after initial help
|
|
✅ Validates a service we're building anyway
|
|
✅ Setup time < 30 minutes
|
|
✅ No ongoing maintenance needed
|
|
✅ Doesn't impact critical path
|
|
✅ Michael has time and energy
|
|
|
|
---
|
|
|
|
## FRIEND ASSISTANCE LOG
|
|
|
|
### Holly (February 11, 2026)
|
|
- **Need:** [To be determined in her project]
|
|
- **Offered:** TBD
|
|
- **Timeline Impact:** TBD
|
|
- **Status:** In progress
|
|
|
|
### [Future Friend 2]
|
|
- **Need:**
|
|
- **Offered:**
|
|
- **Timeline Impact:**
|
|
- **Status:**
|
|
|
|
---
|
|
|
|
## FOR NEW CLAUDE IN FRIEND ASSISTANCE PROJECT
|
|
|
|
**Your job is to:**
|
|
|
|
1. ✅ Understand the friend's actual need (not assume)
|
|
2. ✅ Evaluate if Firefrost infrastructure fits (honestly)
|
|
3. ✅ Consider alternatives (don't force our tools)
|
|
4. ✅ Assess timeline impact (protect critical path)
|
|
5. ✅ Make clear recommendation (help/don't help/partial)
|
|
6. ✅ Generate handoff document (if help provided)
|
|
|
|
**You are NOT:**
|
|
- ❌ Obligated to use Firefrost tools
|
|
- ❌ Building new services for one person
|
|
- ❌ Committing to ongoing support without Michael's agreement
|
|
- ❌ Ignoring better solutions elsewhere
|
|
|
|
**Remember:**
|
|
- Michael WANTS to help friends
|
|
- But must be sustainable
|
|
- And protect Firefrost timeline
|
|
- And respect his health/energy limits
|
|
|
|
**Your role is to find the balance.**
|
|
|
|
---
|
|
|
|
## TEMPLATE: FRIEND ASSISTANCE EVALUATION
|
|
|
|
Copy this into friend assistance project after understanding need:
|
|
```markdown
|
|
# INFRASTRUCTURE EVALUATION FOR [FRIEND NAME]
|
|
|
|
## Their Need:
|
|
[What they're trying to accomplish]
|
|
|
|
## Firefrost Services Evaluated:
|
|
|
|
### [Service 1]:
|
|
- **Fits need?** Yes/No/Partial
|
|
- **Setup time:** X minutes
|
|
- **Ongoing maintenance:** None/Low/High
|
|
- **Better than alternatives?** Yes/No
|
|
- **DECISION:** Offer / Don't Offer / Suggest Alternative
|
|
|
|
### [Service 2]:
|
|
[Same format]
|
|
|
|
## Overall Recommendation:
|
|
**[HELP / DON'T HELP / PARTIAL HELP / WAIT UNTIL X]**
|
|
|
|
## If Helping:
|
|
- **Services to provide:** [List]
|
|
- **Setup time estimate:** [X minutes/hours]
|
|
- **Timeline impact:** None/Minor/Requires discussion
|
|
- **Handoff items:** [What Firefrost Claude needs to know]
|
|
|
|
## If Not Helping:
|
|
- **Reason:** [Clear explanation]
|
|
- **Alternatives suggested:** [What they should use instead]
|
|
- **Future possibility:** [Could we help later? When?]
|
|
```
|
|
|
|
---
|
|
|
|
**Fire + Frost + Helping Friends Sustainably** 🔥❄️🤝
|
|
|
|
---
|
|
|
|
**Version:** 1.0
|
|
**For:** ANY Claude working on friend/family assistance
|
|
**Purpose:** Evaluate infrastructure fit, protect timeline, generate handoff
|
|
**Status:** Active protocol
|
|
|
|
**Michael values helping people. Claude helps Michael help sustainably.** 💙
|