Skip to content
Seed & Source Docs

Seed & Source Alpha Support Guide

Seed & Source Alpha Support Guide

Last Updated: February 2026 Program Phase: Alpha Testing (30-90 day access) Support Level: Priority Alpha Support

Welcome to Alpha Support

Thank you for participating in the Seed & Source Alpha program! This guide explains how to get help, report issues, and provide feedback during your alpha testing period.

🚀 Getting Started First

Before requesting support, please check these resources:

Self-Service Documentation

  1. Onboarding Checklist - Step-by-step setup guide
  2. Troubleshooting Guide - Common issues and solutions
  3. Getting Started - Basic usage documentation
  4. CLI Quick Reference - Command reference

Quick Diagnostic Commands

Run these to collect diagnostic information before reporting issues:

Terminal window
# Check your environment
sscli doctor


# Verify your license
sscli license status


# View system information
sscli version --verbose

📞 Support Channels

Primary Channel: GitHub Issues (Preferred)

Use for: Bug reports, feature requests, technical issues

Link: https://github.com/seed-source/foundry-meta/issues

Why GitHub?

  • ✅ Transparent tracking
  • ✅ Searchable knowledge base
  • ✅ Community benefit
  • ✅ Direct link to code fixes

Before Creating an Issue:

  1. Search existing issues: https://github.com/seed-source/foundry-meta/issues
  2. Check if your issue is already reported
  3. Add a comment to existing issues rather than duplicating

Creating a New Issue:

  1. Go to GitHub Issues page
  2. Click “New Issue”
  3. Select appropriate template (Bug Report or Feature Request)
  4. Fill in all required fields
  5. Attach logs and screenshots if applicable

Secondary Channel: Email Support

Use for: Private/confidential issues, license questions, contract discussions

Email: alpha-support@seedsource.dev (response within 24 hours)

What to Include:

  • Your registered email address
  • Alpha User ID (found in foundry/.tier)
  • Brief description of issue
  • Link to GitHub issue if applicable

Emergency Contact

Use ONLY for: Critical blockers preventing all work

Criteria for Emergency:

  • License server completely unavailable
  • Data loss or corruption
  • Security vulnerability discovered
  • Complete system failure with no workaround

Contact: engineering@seedsource.dev with subject line: [ALPHA CRITICAL]

⏱️ Response Time Expectations

Critical Issues (Priority 1)

Definition: Complete blocker preventing onboarding or deployment

  • License server unavailable
  • Cannot initialize any template
  • Data loss or security issue

Response Time: Within 4 hours (business hours) Resolution Target: Same business day or documented workaround provided Business Hours: Monday-Friday, 9 AM - 6 PM PST

High Priority (Priority 2)

Definition: Feature not working as documented, but workaround exists

  • Template generation fails for specific configuration
  • Docker build errors with known alternative
  • CLI command error with manual workaround available

Response Time: Within 24 hours Resolution Target: Within 3 business days or patch in next release

Medium Priority (Priority 3)

Definition: Non-blocking issues or enhancement requests

  • Documentation clarification needed
  • Minor cosmetic issues
  • Feature enhancement suggestions
  • Performance optimization ideas

Response Time: Within 48 hours Resolution Target: Prioritized for future release (no guarantee during alpha)

Low Priority (Priority 4)

Definition: Nice-to-have improvements

  • Documentation typos
  • Minor UI polish
  • Edge case scenarios
  • Future feature ideas

Response Time: Within 1 week Resolution Target: Backlog for post-alpha consideration

Business Hours & Holidays

  • Timezone: Pacific Standard Time (PST/PDT)
  • Business Days: Monday through Friday
  • Weekends: No guaranteed response (monitored for critical issues only)
  • Holidays: Response times may be extended by 1-2 days

🐛 Bug Reporting Workflow

1. Reproduce the Issue

Before reporting, try to reproduce the bug consistently:

  • Note exact steps taken
  • Try on fresh environment if possible
  • Test with different configurations

2. Gather Diagnostic Information

Run these commands and save the output:

Terminal window
# System diagnostics
sscli doctor > diagnostics.txt


# License verification
sscli license status >> diagnostics.txt


# Version information
sscli version --verbose >> diagnostics.txt


# Docker status (if relevant)
docker ps >> diagnostics.txt
docker-compose ps >> diagnostics.txt

3. Create GitHub Issue

Use the Bug Report template and include:

Required Information:

  • Clear description of expected vs actual behavior
  • Step-by-step reproduction instructions
  • Error messages (full output, not paraphrased)
  • Environment details (OS, versions, Docker info)
  • Screenshots or screen recordings (if UI-related)
  • Diagnostics output from step 2

Optional but Helpful:

  • Logs from ~/.sscli/logs/
  • Docker container logs
  • Network capture (for license server issues)
  • Minimal reproduction repository

4. Response Process

  1. Acknowledgment - Issue labeled and acknowledged within SLA
  2. Triage - Team reviews and prioritizes
  3. Investigation - We reproduce and diagnose
  4. Resolution - Fix provided via patch or workaround
  5. Verification - You confirm fix resolves issue
  6. Closure - Issue closed with resolution notes

💡 Feature Request Process

What Makes a Good Feature Request?

Strong Feature Requests include:

  • Problem Statement: What pain point does this solve?
  • Use Case: Real scenario from your workflow
  • Proposed Solution: How you envision it working
  • Alternatives: What workarounds did you try?
  • Impact: How critical is this to your work?

Example of Strong Feature Request:

Problem: Managing multiple environment configurations is error-prone
Use Case: Developer needs dev/staging/prod configs for 3 templates
Proposed Solution: `sscli config switch --env staging` command
Alternatives: Manual .env file swapping (prone to mistakes)
Impact: HIGH - Blocks our staging deployment workflow

Feature Request Lifecycle

  1. Submission - Create issue with Feature Request template
  2. Review - Team evaluates feasibility and priority
  3. Discussion - We may ask clarifying questions
  4. Decision - Accepted, deferred, or declined (with reasoning)
  5. Implementation - Added to roadmap if accepted
  6. Release - Included in future version with release notes

Setting Expectations

  • Not all requests will be implemented during alpha
  • We prioritize based on user impact and feasibility
  • Some features may be planned for post-launch
  • Your input shapes our roadmap (high value)

🚫 Not Supported During Alpha

To set clear expectations, the following are explicitly out of scope during the alpha period:

❌ Out of Scope

  • Production Deployment Support - Alpha is for development environments only
  • Custom Integration Development - Beyond documented templates and extensions
  • Code Review Services - We don’t review your generated project code
  • Phone Support - All support via GitHub/email only
  • 24/7 Support - Business hours only (see SLA section above)
  • Guaranteed Uptime - License server may have maintenance windows
  • Custom Feature Rush Requests - No guaranteed turnaround for special requests
  • Training/Consulting - No 1-on-1 training sessions during alpha
  • Multi-Environment Setup - Kubernetes, AWS deployments (focus on local Docker)
  • Performance Tuning - For your specific hardware/network conditions

✅ What IS Supported

  • Template Generation - All documented templates and flags
  • Local Docker Development - docker-compose orchestration
  • CLI Functionality - All sscli commands and features
  • License Management - Activation, status, troubleshooting
  • Documentation Clarification - Corrections and improvements
  • Bug Fixes - For issues reproducible in standard environments
  • Feature Feedback - Your input on existing features
  • Workaround Assistance - Helping you unblock with alternative approaches

🔄 Escalation Process

Most issues are resolved through normal GitHub issue workflow. However, if you feel your issue needs escalation:

When to Escalate

  • Issue labeled “Critical” with no response within SLA
  • Blocking issue with no workaround after 2 business days
  • Security vulnerability requiring immediate attention
  • Repeated support failures or communication breakdown

How to Escalate

  1. Add comment to existing issue: Tag with @seed-source/engineering and explain escalation reason
  2. Email: Send to alpha-support@seedsource.dev with subject [ESCALATION] Issue #123
  3. Include: Issue number, original report date, escalation reason, business impact

Escalation Response

  • Escalations reviewed by engineering lead within 4 hours (business hours)
  • Direct communication established
  • Resolution plan provided within 24 hours

📊 Feedback Collection

Your feedback is invaluable! We collect feedback through multiple channels:

Structured Feedback (Preferred)

Typeform Survey (sent via email)

  • Weekly check-ins during alpha
  • End-of-alpha comprehensive survey
  • Feature-specific surveys

Unstructured Feedback

  • Comments on GitHub issues
  • Feature request discussions
  • Email responses to support threads
  • Ad-hoc conversations

What We’re Looking For

  • Usability: Is the CLI intuitive? Documentation clear?
  • Functionality: Do templates work as expected?
  • Performance: Generation speed, Docker startup times?
  • Blockers: What prevents you from using this daily?
  • Wishlist: What features would make this exceptional?

📋 Support Best Practices

For Fastest Resolution

Do’s ✅

  • Search existing issues first
  • Provide complete reproduction steps
  • Include all diagnostic information
  • Use issue templates
  • Test with latest version
  • Try suggested workarounds
  • Follow up when issue is resolved

Don’ts ❌

  • Don’t create duplicate issues
  • Don’t ping multiple channels simultaneously
  • Don’t demand immediate fixes
  • Don’t skip required information in templates
  • Don’t ignore workarounds without trying them
  • Don’t be rude (we’re humans too!)

🎓 Common Issue Resolution Paths

”License Activation Failed”

  1. Check: sscli license status
  2. Verify: Internet connectivity to license-server.seedsource.dev
  3. Confirm: Email matches alpha invitation
  4. Check: Firewall/VPN not blocking HTTPS
  5. Try: sscli license activate --email your@email.com --force
  6. Still stuck? Create GitHub issue with full error output

”Template Generation Failed”

  1. Run: sscli doctor to check prerequisites
  2. Verify: Docker is running (docker ps)
  3. Check: Disk space (df -h)
  4. Try: sscli init [template] --verbose for detailed output
  5. Check: Logs in ~/.sscli/logs/
  6. Still stuck? Create GitHub issue with log files

”Docker Build Failing”

  1. Pull latest images: docker-compose pull
  2. Clean rebuild: docker-compose build --no-cache
  3. Check: Docker daemon memory/CPU limits
  4. Try: Single service: docker-compose up [service]
  5. Review: Service-specific logs
  6. Still stuck? Create GitHub issue with docker-compose logs

📞 Contact Summary

ChannelUse ForResponse Time
GitHub IssuesBugs, features, technical issues4-48 hours (by priority)
Email (alpha-support@)Private issues, license questions24 hours
Emergency EmailCritical blockers only4 hours (business hours)

🤝 Support Philosophy

During alpha, we commit to:

  • Transparency: Public issue tracking when possible
  • Responsiveness: Meeting SLA targets consistently
  • Honesty: Clear “yes/no/maybe” on feature requests
  • Collaboration: Working WITH you to resolve blockers
  • Respect: Valuing your time and feedback

We ask that you:

  • Be Patient: Alpha software has rough edges
  • Be Thorough: Provide complete information
  • Be Engaged: Try workarounds and respond to questions
  • Be Constructive: Feedback over complaints
  • Be Awesome: Help us make this the best developer tool possible

📚 Additional Resources

Questions about this support process? Contact: alpha-support@seedsource.dev

Found an error in this guide? Create an issue: https://github.com/seed-source/foundry-meta/issues