firefrost-gaming/firefrost-operations-manual
3
0
Fork 0
Code Issues 146 Pull Requests Packages Projects Releases Wiki Activity
Files
master
firefrost-operations-manual/docs/external/friend-assistance-protocol.md

13 KiB
Raw Permalink Blame History

🤝 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:

## 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:

# 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:

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

Reference in New Issue View Git Blame Copy Permalink