# 🤝 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.** 💙