# SPMT Documentation Complete public documentation bundle for spmt.live. Ecosystem snapshot: 2026-09-11T18:18:41.026Z Ecosystem schema: spmt.ecosystem-state/v1 This file is generated from `docs/docs-nav.json` during the application image build. Edit the source Markdown files, not this generated bundle. --- ## Start Here # SpaceMountain Documentation Welcome to the SpaceMountain documentation hub. SpaceMountain is a connected creator operating system. It combines a creator identity layer, a command bridge, app management, unified communication, AI orchestration, and specialized creator apps. ## Start Here | Audience | Start With | Goal | |---|---|---| | Creators | `creator/GETTING_STARTED.md` | Learn how to use the ecosystem | | Developers | `developers/QUICKSTART.md` | Learn how to build or integrate apps | | Partners and Crew | `legal/README.md` | Review the owner-approved Community Terms package | | Contributors | `CONTRIBUTING.md` | Learn where features belong | | Product/Marketing | `business/POSITIONING.md` | Learn how to describe the platform | ## Raw / Offline Documentation The docs site reads the Markdown sources listed in `docs/docs-nav.json` directly. - Open `/docs/all.md` to view the complete public documentation as one Markdown document. - Use **Download All (.md)** on the docs page to save the same bundle as `SPMT-DOCS.md`. - The bundle is generated automatically during the application image build from the navigation manifest, so it should never be edited as a separate source of truth. - Archived and internal-only documents are not included unless they are deliberately added to the public navigation manifest. ## Core Concepts - **SPMT / Creator Cloud** — identity, platform APIs, event bus, app registry, Commlink data, Athena context. - **SpaceMountain.live / Command Bridge** — the user-facing workspace and launcher. - **Shipyard** — app discovery, install state, permissions, health, and launch flow. - **Commlink** — unified messages, app events, notifications, forums, and AI conversations. - **Athena** — operating intelligence for the ecosystem. - **Event Bus** — how apps publish events without hard-coding direct integrations. ## Read Next 1. `VISION.md` 2. `ARCHITECTURE.md` 3. `creator/GETTING_STARTED.md` 4. `platform/EVENT_BUS.md` 5. `developers/APP_INTEGRATION_GUIDE.md` 6. `legal/README.md` --- # SpaceMountain Vision ## Mission Build the operating system for creators. SpaceMountain is not just a streamer dashboard or a bundle of tools. It is a connected ecosystem where identity, communication, automation, AI, games, community, and creator apps reinforce each other. ## The Big Idea Creators should not need to manage five dashboards, five logins, five inboxes, and five disconnected sets of community data. They should have: - one identity - one command bridge - one app launcher - one communications hub - one AI with ecosystem awareness - specialized apps that become more powerful together ## The Product Layers ### SPMT — Creator Cloud SPMT owns shared services: identity, app registry, permissions, event bus, Commlink data, Athena context, app lifecycle, API keys, webhooks, and platform integrations. ### SpaceMountain.live — Command Bridge SpaceMountain.live owns the creator experience: dashboard, app launcher, docs, Commlink UI, Shipyard UI, Athena UI, widgets, docked app slots, and workspace navigation. ### Ecosystem Apps Each app owns a focused capability: - Discord Stream Hub: Discord/community operations - StreamWeaver: stream automation and overlays - HearMeOut: rooms, voice, music, watch parties - ChatTag: live community games and rewards - Quackverse: game/card ecosystem - MountainView: future devices, QR, voice, camera workflows ## Success Test A new feature belongs in SPMT if every app can benefit from it. A new feature belongs in SpaceMountain.live if it is user-facing command, navigation, visualization, or dashboard work. A new feature belongs in an app if it is specific to that app's purpose. --- # Architecture ## High-Level Map ```mermaid flowchart TD Creator[Creator] --> Bridge[SpaceMountain.live / Command Bridge] Bridge --> SPMT[SPMT / Creator Cloud] SPMT --> Identity[Identity] SPMT --> Shipyard[Shipyard] SPMT --> Commlink[Commlink] SPMT --> Athena[Athena OS] SPMT --> EventBus[Event Bus] EventBus --> SW[StreamWeaver] EventBus --> DSH[Discord Stream Hub] EventBus --> HMO[HearMeOut] EventBus --> CT[ChatTag + Quackverse] EventBus --> MV[MountainView] ``` ## SPMT Responsibilities SPMT should answer: - Who is the user? - What apps can they access? - What apps are installed? - What permissions are granted? - What messages and notifications exist? - What events happened? - What context should Athena know? ## SpaceMountain.live Responsibilities SpaceMountain.live should present: - the current creator workspace - app launch state - notifications - Commlink - Athena - docs - controls - dashboards - embedded/docked app surfaces ## App Responsibilities Apps should focus on their specialty and publish useful ecosystem events. They should not duplicate authentication, user profiles, global notifications, cross-app messaging, app registry state, or Athena memory. --- # Glossary ## SPMT The Creator Cloud. Owns shared identity, APIs, event bus, app registry, Commlink data, and Athena context. ## SpaceMountain.live The Command Bridge. The primary user-facing workspace. ## Shipyard The app lifecycle manager: discover, install, enable, launch, update, disable. ## Commlink The unified communication system for messages, app events, notifications, forums, and AI conversations. ## Athena Operating Intelligence. The AI layer that understands the creator's ecosystem. ## Event Bus The cross-app integration model. Apps publish events and SPMT routes them to the right consumers. ## Ecosystem App A specialized app that plugs into SPMT and benefits from shared identity, communication, and context. --- # FAQ ## What is SpaceMountain? SpaceMountain is a creator operating system: one connected workspace for streamer tools, community workflows, AI, games, apps, and automation. ## What is SPMT? SPMT is the Creator Cloud behind SpaceMountain. It owns identity, app registry, platform APIs, events, Commlink data, and Athena context. ## What is SpaceMountain.live? SpaceMountain.live is the Command Bridge: the interface creators use every day. ## Why should creators care? Because disconnected dashboards waste time. SpaceMountain gives creators one place to launch apps, read updates, manage community activity, and coordinate with Athena. ## Why should developers care? Because SPMT gives developers identity, app registration, Commlink, events, webhooks, and Athena context so they can focus on their actual app. ## Is every app required? No. Shipyard should let users install and enable only the apps they want. --- # Contributing Before changing code, understand the platform boundaries. ## Decision Checklist Ask: 1. Does this belong in SPMT? 2. Does this belong in SpaceMountain.live? 3. Does this belong in one app? 4. Should this be represented as an ecosystem event? 5. Does this duplicate identity, messaging, notifications, or app registry logic? ## Rules - SPMT owns shared services. - SpaceMountain.live owns the command bridge UI. - Apps own app-specific features. - Keep commits small and reviewable. - Update docs when changing integration contracts. --- ## Creator Guide # Creator Getting Started ## Step 1: Create your SPMT account Your `@spmt.live` account is your creator identity across the ecosystem. ## Step 2: Open SpaceMountain.live SpaceMountain.live is your Command Bridge. ## Step 3: Link accounts Connect platforms such as Twitch and Discord so apps can understand who you are across communities. ## Step 4: Open Shipyard Install or enable apps such as Discord Stream Hub, StreamWeaver, HearMeOut, ChatTag, Quackverse, and MountainView. ## Step 5: Use Commlink Commlink collects messages, notifications, forum activity, app events, and AI conversations. ## Step 6: Work with Athena Athena helps summarize, route, and understand activity across your connected apps. --- # Creator Journey ```mermaid sequenceDiagram participant C as Creator participant S as SPMT participant B as SpaceMountain.live participant A as Apps participant AI as Athena C->>S: Create @spmt.live account C->>B: Open Command Bridge B->>S: Load identity and installed apps C->>B: Install apps from Shipyard B->>A: Launch app A->>S: Publish ecosystem event S->>AI: Store useful context S->>B: Show notification in Commlink ``` The goal is that every app feels like part of the same workspace, not a separate website. --- # Real-World Workflows ## Stream Night Command Center 1. Creator signs into SpaceMountain. 2. Shipyard shows installed apps. 3. StreamWeaver prepares automations. 4. Discord Stream Hub finds live partners. 5. ChatTag starts a reward event. 6. HearMeOut opens a room. 7. Commlink collects updates. 8. Athena summarizes what needs attention. ## Community Game Night 1. ChatTag starts a game. 2. Quackverse rewards unlock. 3. Discord Stream Hub announces results. 4. StreamWeaver triggers overlays. 5. Commlink stores important events. 6. Athena summarizes winners and activity. ## Watch Party 1. HearMeOut starts a room. 2. Commlink sends invites. 3. SpaceMountain displays room status. 4. Athena routes commands to open the room. 5. Discord Stream Hub can mirror community updates. --- # Using Shipyard Shipyard is where creators manage apps. ## What Shipyard Shows - installed apps - available apps - app status - versions - updates - permissions - launch buttons ## Why It Matters Creators should not need to bookmark every tool separately. Shipyard should become the launch bay for the ecosystem. --- # Using Commlink Commlink is the unified communication workspace. It can include: - direct messages - notifications - app updates - bot messages - forum activity - room invites - reward events - AI conversations The goal is simple: important ecosystem activity should not get lost inside separate apps. --- # Using Athena Athena is the operating intelligence of the creator ecosystem. Athena should help answer: - What happened while I was away? - Which apps need attention? - Who messaged me? - What stream or community events are important? - Which app should open for this command? Athena is most useful when apps publish events and write helpful context back to SPMT. --- ## Platform # Identity SPMT is the canonical identity provider for the SpaceMountain ecosystem. ## Identity Goals - One `@spmt.live` account. - One immutable SPMT user ID for ecosystem ownership and attribution. - Linked Twitch and Discord accounts without making provider usernames the primary identity. - Shared account context across apps. - OAuth and session restore paths for first-party apps. - Existing app users can migrate without being forced to create a second account. ## Canonical Identity vs. Linked Providers An SPMT account is the ecosystem identity. Twitch and Discord records are linked provider identities. Apps should store and reference the immutable SPMT user ID for shared ownership. Provider IDs may be attached for provider-specific actions and attribution, but provider display names and usernames are not proof that two accounts belong to the same person. ## Provider-Owned / Imported Accounts Trusted first-party apps can grandfather an existing user only after verifying an immutable provider ID through an app-bound server credential. Imported identities: - immediately receive a stable SPMT user ID; - do not require an invented password; - can later claim credentials from a verified session; - must not be merged by display name alone; - retain their SPMT identity when credentials are claimed or providers are linked. ## Sessions and OAuth Browser/session calls use the authenticated SPMT user session. Ecosystem apps should use the SPMT OAuth authorization-code flow to obtain app-bound access to the same canonical identity. Server-to-server privileged operations use scoped platform credentials instead of borrowing a user's browser token. See `developers/OAUTH_FLOW.md` for the first-party OAuth sequence and migration rules. ## App Rule Apps should ask SPMT who the user is instead of creating separate ecosystem identities. App-owned profile fields and state may remain in the app, but they should attach to the SPMT user ID. If SPMT identity is unavailable, the app should show a recoverable authentication state rather than silently generating a fake user. --- # Shipyard Shipyard manages app lifecycle. ```mermaid flowchart LR Discover --> Install --> Configure --> Enable --> Launch --> Update --> Disable --> Uninstall ``` ## App Metadata Every app should provide: - id - name - description - launch URL - auth URL - version - latest version - health status - permissions - install state --- # Commlink Commlink is the unified communications layer. ## Sources - direct messages - app messages - forum replies - notifications - AI conversations - room invites - reward events - automation events ## Principle If an event matters to a user, it should be visible in Commlink or notifications. --- # Athena OS Athena is the operating intelligence layer. ## Responsibilities - Understand the signed-in creator. - Know installed apps. - Read relevant ecosystem context. - Route creator commands. - Summarize app activity. - Remember useful context. - Help creators manage the workspace. ## App Integration Apps should send Athena useful summaries, not noisy raw logs. --- # Ecosystem Event Bus The Event Bus prevents tight coupling between apps. Apps publish events. SPMT routes those events to subscribers such as Athena, Commlink, notifications, analytics, and future apps. ```mermaid flowchart TD App[App publishes event] --> Bus[SPMT Event Bus] Bus --> Commlink Bus --> Athena Bus --> Notifications Bus --> Analytics Bus --> OtherApps[Other Apps] ``` ## Event Shape ```json { "id": "evt_123", "type": "reward.earned", "sourceApp": "chat-tag", "actor": "user_123", "timestamp": "2026-07-04T12:00:00Z", "payload": {} } ``` --- # Event Catalog ## Identity - `user.created` - `user.updated` - `user.linked_account.connected` ## Streaming - `stream.started` - `stream.ended` - `automation.completed` - `overlay.updated` ## Community - `discord.shoutout.created` - `forum.post.created` - `community.member.joined` ## Voice And Rooms - `voice.room.created` - `voice.room.closed` - `music.track.changed` ## Games And Rewards - `game.started` - `game.finished` - `reward.earned` - `leaderboard.updated` ## Apps And Platform - `app.installed` - `app.disabled` - `app.updated` - `plugin.installed` ## Athena - `athena.memory.created` - `athena.command.executed` --- # Event Payloads This document defines example event payloads for common ecosystem events. ## `stream.started` ```json { "type": "stream.started", "sourceApp": "streamweaver", "actor": "user_123", "payload": { "platform": "twitch", "channel": "mtman1987", "title": "Late night creator lab" } } ``` ## `discord.shoutout.created` ```json { "type": "discord.shoutout.created", "sourceApp": "discord-stream-hub", "actor": "user_123", "payload": { "creator": "PartnerName", "platform": "twitch", "reason": "Went live" } } ``` ## `reward.earned` ```json { "type": "reward.earned", "sourceApp": "chat-tag", "actor": "user_456", "payload": { "rewardId": "reward_789", "rewardName": "Tag Champion", "points": 500 } } ``` ## `voice.room.created` ```json { "type": "voice.room.created", "sourceApp": "hearmeout", "actor": "user_123", "payload": { "roomId": "room_123", "title": "Community Watch Party" } } ``` ## `athena.command.executed` ```json { "type": "athena.command.executed", "sourceApp": "athena", "actor": "user_123", "payload": { "command": "open active room", "target": "hearmeout" } } ``` --- # Integration Patterns ## Pattern 1: App Event To Commlink An app completes something important. 1. App publishes event. 2. SPMT stores event. 3. SPMT creates a notification if user-facing. 4. SpaceMountain.live shows it in Commlink. ## Pattern 2: App Event To Athena An app creates useful context. 1. App publishes event. 2. SPMT summarizes or stores relevant details. 3. Athena can use it later for command routing or summaries. ## Pattern 3: Shipyard Launch 1. User opens SpaceMountain.live. 2. User opens Shipyard. 3. Shipyard loads apps from SPMT. 4. User launches app. 5. App restores SPMT identity. ## Pattern 4: Cross-App Benefit ChatTag publishes `reward.earned`. - Commlink notifies the creator. - Athena remembers the win. - StreamWeaver may trigger an overlay. - Discord Stream Hub may announce it. --- # App Lifecycle Every ecosystem app should follow the same lifecycle: 1. Discover 2. Install 3. Configure 4. Enable 5. Launch 6. Update 7. Disable 8. Uninstall Shipyard should display lifecycle state clearly so users understand whether an app is ready, connected, disabled, or waiting for setup. --- # Permissions Permissions define what an app or platform credential can do through SPMT. ## Current Public Scope Families Current platform scope names include: - `identity:read` - `identity:write` - `apps:read` - `apps:write` - `messages:read` - `messages:write` - `athena:write` - `events:write` - `webhooks:write` - `xp:write` A capability appearing in UI or documentation does not mean every client receives it automatically. The credential must be issued with the required scope and, for privileged server operations, bound to the correct app/environment. ## User Sessions vs. Platform Credentials User sessions and OAuth access tokens represent a signed-in person. They should be used for actions the user is authorized to perform. Platform API keys represent a trusted app/backend. They are intended for server-to-server operations and must remain off the public client. Do not use a platform credential merely to bypass a user permission check. ## Principles - Ask for the minimum permissions required. - Explain user-facing permissions in understandable language. - Keep privileged credentials server-side. - Bind service credentials to the owning app/environment where supported. - Make credentials revocable and rotatable. - Test both allowed and forbidden calls. - Do not infer authorization from an app name, display name, provider username, or unverified request metadata. - Keep tenant/user context explicit when the operation reads or writes tenant-owned state. ## Examples A read-only identity consumer may only need `identity:read`. A trusted migration backend that verifies existing provider accounts may require `identity:write`. An event producer may require `events:write`. A canonical XP producer requires `xp:write` and must still satisfy the app-bound XP contract and idempotency rules. Requesting a broader scope set than the app uses increases risk and should be treated as an integration defect. --- # Data Ownership ## SPMT Owns - shared user identity - linked account references - app install state - shared permissions - Commlink data - notifications - ecosystem event records - Athena context summaries ## Apps Own - app-specific settings - app-specific game state - room state - stream automation configuration - overlay configuration - feature-specific data ## Rule If the data helps multiple apps understand the same user or event, SPMT should probably know about it. --- # Observability The platform should make ecosystem health visible. ## Health Signals SPMT should expose: - API uptime - database health - app registry status - active app count - conversation count - notification count - event processing status - platform plugin status Apps should expose: - health URL - version - latest version - adapter status - auth status where safe - last successful event publish ## Command Bridge SpaceMountain.live should summarize health in user-friendly language. Example: > StreamWeaver is online. HearMeOut needs attention. ChatTag has an update available. --- # Security Model ## Identity SPMT owns canonical ecosystem identity and session validation. Apps should attach app-owned data to the immutable SPMT user ID. Twitch/Discord display names are not identity proof; provider reconciliation must use verified immutable provider IDs. ## Authentication Boundaries Use the credential that matches the actor: - signed-in user session or bearer token for user actions; - OAuth access token for an app acting with the user's authorized SPMT identity; - scoped, app-bound platform credential for trusted server-to-server operations. A server credential must not be used to bypass a user authorization decision. ## OAuth - Register exact callback URLs. - Validate application `state`. - Exchange authorization codes on the backend. - Treat authorization codes as one-time credentials. - Keep OAuth client secrets server-side. - Re-authorize or refresh instead of creating a replacement identity when tokens expire. ## Secrets Secrets belong in server-side environment/secret stores, not browser bundles, public repositories, logs, event payloads, or generated documentation. Do not print full service keys, OAuth client secrets, refresh tokens, session tokens, or provider credentials in diagnostics. ## Platform API Keys Platform API keys should be: - scoped; - app/environment bound where supported; - revocable and rotatable; - hashed or otherwise protected at rest; - checked for the required capability before privileged actions; - isolated from public/browser code. ## Tenant and Account Isolation Shared platform features must keep tenant/user ownership explicit. Missing tenant context should fail closed when the operation would otherwise read or write tenant-owned state. Cross-app migration and reconciliation must not merge accounts from loose aliases or matching display names. ## Event and XP Safety Events should use stable IDs and bounded payloads without raw secrets or private logs. Canonical XP awards require a stable SPMT user ID plus an upstream/idempotency identifier. Retries reuse that identifier so a repeated delivery cannot award points twice. ## Companion / Device Control Paired Companion devices receive explicit capabilities. Device commands are constrained to supported action/capability mappings; higher-impact commands may require confirmation and expire if they are not completed in time. ## Failure Behavior Security-sensitive failures should be visible and recoverable, not silently converted into a fake account, broad credential fallback, or simulated success. --- # Release Checklist Before shipping an ecosystem change: ## Build - Run local build. - Verify no obvious TypeScript or bundling errors. - Confirm docs still match behavior. ## Platform Contract - Did an endpoint change? - Did an event shape change? - Did an app metadata field change? - Did an auth/session behavior change? If yes, update docs. ## App Impact Check: - SpaceMountain.live - SPMT - Discord Stream Hub - StreamWeaver - HearMeOut - ChatTag - Quackverse - MountainView ## Live Verification Check: - app loads - identity restores - apps list appears - Commlink opens - Docs page opens - critical APIs return expected status --- # API Reference This page summarizes the supported SPMT integration surfaces. The SDK should be preferred for application code because it applies the expected authentication mode and shared contracts. ## Current Ecosystem Snapshot - Public SPMT URL: `https://spmt.live` - API base URL: `https://spmt.live/api` - Repository: `Mtman1987/spmt-live` - Current Fly service state: `unobserved` - Snapshot observed: `2026-09-11T18:18:41.026Z` These values come from the public `spmt.ecosystem-state/v1` snapshot produced by MTMan Machine Rotator. Lifecycle/capability declarations remain separate from observed runtime health. ## Authentication Modes ### User session / bearer token Use for actions performed as the signed-in SPMT user. Browser/session SDK calls use the user's SPMT session or bearer token. ### OAuth access token First-party and third-party apps use the authorization-code flow to obtain an access token representing the same canonical SPMT identity. ### Scoped platform API key Use for trusted server-to-server operations such as publishing platform events, grandfathering verified identities, or awarding canonical XP. Keys are app-bound, scoped, and should never be shipped to browser code. ## Identity and OAuth - `GET /api/me` — current signed-in SPMT user. - `POST /api/auth/refresh` — refresh the current SPMT user session. - `POST /api/auth/claim-imported` — claim credentials for an eligible imported/provider-owned identity. - `GET /api/oauth/authorize` — begin OAuth authorization-code flow. - `POST /api/oauth/token` — exchange a one-time authorization code or other supported OAuth grant. - `GET /api/oauth/userinfo` — read the canonical SPMT identity for an OAuth access token. - `POST /api/platform/identity/grandfather` — trusted app-bound migration of a verified provider identity. See `developers/OAUTH_FLOW.md` for the application flow and migration rules. ## Apps / Shipyard - `GET /api/apps` - `GET /api/apps/:appId` - `GET /api/apps/:appId/versions` - `POST /api/apps/:appId/install` - `POST /api/apps/:appId/disable` - `POST /api/platform/apps` — developer/app submission surface. ## Workspace and Overlays - `GET /api/workspace-profile` - `PATCH /api/workspace-profile` - `PUT /api/workspace-profile` - `POST /api/workspace-profile/reset` - `GET /api/overlay-workspace` Workspace writes use revision-aware `WorkspaceProfileV1` contracts. Apps should use SDK helpers instead of independently inventing workspace preference formats. ## Commlink - `GET /api/conversations` - `GET /api/notifications` - `GET /api/search` - `GET /api/messages` Commlink also has SDK-owned shared-chat, dispatch, operator, and integration contracts. Use the SDK/spec documentation for those versioned payload shapes instead of inferring them from UI responses. ## Events - `POST /api/events` — publish as the authenticated user/session where allowed. - `POST /api/platform/events` — publish with a scoped platform credential. - `GET /api/platform/events` — server-side event history for authorized integrations. Event producers should send stable IDs and retry idempotently. ## Experience / XP - `GET /api/xp` — current user's canonical XP and derived level. - `POST /api/platform/xp` — app-bound, scoped canonical XP award endpoint. XP producers must use the canonical SPMT user ID and a stable upstream event/message ID so retries cannot double-award points. ## Athena - `GET /api/athena/os` - `GET /api/athena/context` - `POST /api/athena/commands` Athena surfaces must report configured, degraded, unavailable, or accepted-job state truthfully rather than presenting planned capability as completed behavior. ## Developer Webhooks - `GET /api/platform/webhooks` — list the signed-in developer's registered webhooks. - `POST /api/platform/webhooks` — register an HTTPS webhook and event selection. See `developers/WEBHOOKS.md` for delivery guidance and event-shape rules. ## Companion Authenticated Companion control currently includes device pairing/revocation and command submission/status under `/api/companion/...`, with a WebSocket relay at `/api/companion/relay` for the paired desktop runtime. Use the SDK `Companion*V1` contracts and capability mapping instead of sending arbitrary device actions. ## Platform Discovery - `GET /api/platform` - `GET /api/platform/docs` - `GET /api/platform/plugins` These discovery routes describe public platform capabilities; they are not a substitute for versioned SDK/spec contracts when an operation has one. --- ## Apps # Ecosystem Apps Apps are modules connected by SPMT. Each app should own its specialty and share identity, events, notifications, and context through the platform. ## App Contract Every app should: - use SPMT identity - register with Shipyard - publish events - send important notices to Commlink - write useful context for Athena - expose health/version metadata --- # Discord Stream Hub ## Purpose Discord community tools, shoutouts, calendar, leaderboard, moderation, and community routing. ## Owns This app owns its specific product behavior and app-specific state. ## Publishes - `discord.shoutout.created` - `calendar.event.created` - `moderation.alert` ## Consumes - SPMT identity - Shipyard launch metadata - Commlink notification surfaces - Athena context where useful ## Integration Goal The app should feel like a module of the wider SpaceMountain ecosystem, not a disconnected website. --- # StreamWeaver ## Purpose Stream automation, overlays, TTS, AI generation, commands, and Streamer.bot workflows. ## Owns This app owns its specific product behavior and app-specific state. ## Publishes - `stream.started` - `automation.completed` - `overlay.updated` ## Consumes - SPMT identity - Shipyard launch metadata - Commlink notification surfaces - Athena context where useful ## Integration Goal The app should feel like a module of the wider SpaceMountain ecosystem, not a disconnected website. --- # HearMeOut ## Purpose Voice rooms, music queues, watch parties, shared listening, and room overlays. ## Owns This app owns its specific product behavior and app-specific state. ## Publishes - `voice.room.created` - `voice.room.closed` - `music.track.changed` ## Consumes - SPMT identity - Shipyard launch metadata - Commlink notification surfaces - Athena context where useful ## Integration Goal The app should feel like a module of the wider SpaceMountain ecosystem, not a disconnected website. --- # ChatTag ## Purpose Live community games, overlays, rewards, leaderboards, and arena state. ## Owns This app owns its specific product behavior and app-specific state. ## Publishes - `game.started` - `reward.earned` - `leaderboard.updated` ## Consumes - SPMT identity - Shipyard launch metadata - Commlink notification surfaces - Athena context where useful ## Integration Goal The app should feel like a module of the wider SpaceMountain ecosystem, not a disconnected website. --- # Quackverse ## Purpose Cards, collectibles, game economy, and community progression tied to ChatTag. ## Owns This app owns its specific product behavior and app-specific state. ## Publishes - `card.unlocked` - `pack.opened` - `collection.updated` ## Consumes - SPMT identity - Shipyard launch metadata - Commlink notification surfaces - Athena context where useful ## Integration Goal The app should feel like a module of the wider SpaceMountain ecosystem, not a disconnected website. --- # MountainView ## Purpose Future device/app layer for QR scanning, camera capture, voice commands, and AR-style routing. ## Owns This app owns its specific product behavior and app-specific state. ## Publishes - `device.paired` - `qr.scanned` - `voice.command.received` ## Consumes - SPMT identity - Shipyard launch metadata - Commlink notification surfaces - Athena context where useful ## Integration Goal The app should feel like a module of the wider SpaceMountain ecosystem, not a disconnected website. --- ## Developers # Developer Quickstart For the installable partner SDK and the Atherrea proof, start with [Partner SDK Quickstart](PARTNER_SDK_QUICKSTART.md). ## Goal Build or integrate an app that feels native to the SpaceMountain ecosystem. ## Steps 1. Read the architecture docs. 2. Register the app with SPMT. 3. Use SPMT identity. 4. Add Shipyard metadata. 5. Publish at least one ecosystem event. 6. Send important user-facing updates to Commlink. 7. Add Athena context only when useful. 8. Expose health and version metadata. --- # Build Your First SpaceMountain App This guide shows the ideal app integration path. ## Goal Create an app that: - uses SPMT identity - appears in Shipyard - publishes ecosystem events - sends useful messages to Commlink - provides Athena with helpful context ## Step 1: Define the app Every app needs: ```json { "id": "my-creator-app", "name": "My Creator App", "description": "A useful creator workflow.", "launchUrl": "https://example.com", "healthUrl": "https://example.com/health", "version": "0.1.0", "scopes": ["identity:read", "events:write"] } ``` ## Step 2: Use SPMT identity The app should ask SPMT who the current user is. ```http GET /api/me Authorization: Bearer ``` ## Step 3: Publish an event ```json { "type": "my_app.action.completed", "sourceApp": "my-creator-app", "actor": "user_123", "payload": { "summary": "The app completed a creator workflow." } } ``` ## Step 4: Send user-facing output to Commlink Only important user-facing updates should appear in Commlink. Good examples: - task completed - room invite - automation failed - reward earned - app requires attention Bad examples: - noisy debug logs - repeated heartbeat pings - internal database events ## Step 5: Add Athena context Athena should receive summaries that help the creator understand what happened. Example: > My Creator App completed the scheduled overlay update for tonight's stream. ## Step 6: Test the app journey A healthy app should pass this test: 1. User launches SpaceMountain.live. 2. User opens Shipyard. 3. User installs or launches the app. 4. App knows the SPMT user. 5. App publishes an event. 6. Commlink shows the important result. 7. Athena can summarize the activity. --- # App Integration Guide Use this sequence when connecting an app to SPMT. The goal is to reuse shared platform contracts instead of rebuilding identity, permissions, events, workspace state, or communication independently in every app. ## Current Integration Target - SPMT public URL: `https://spmt.live` - SPMT API base: `https://spmt.live/api` - SPMT repository: `Mtman1987/spmt-live` - Current observed SPMT service state: `unobserved` - Snapshot observed: `2026-09-11T18:18:41.026Z` These values are resolved from `spmt.ecosystem-state/v1`; authored integration guidance below remains the durable contract. ## 1. Decide Ownership First - If every app benefits, build the shared contract in SPMT. - If users see it as part of the main workspace, build the user-facing shell/surface in SpaceMountain.live. - If only one app needs the behavior, keep the implementation and app-owned data in that app. ## 2. Register the App Provide stable app metadata: - app ID and display name; - launch URL; - registered OAuth callback URL where applicable; - health/version metadata; - requested permissions/scopes; - icon/category metadata where needed by Shipyard. Use immutable app IDs in contracts and credentials. Do not use a display name as an authorization identifier. ## 3. Use SPMT Identity For user-facing ecosystem identity, use SPMT OAuth/session restore rather than creating a duplicate account. - Browser/user actions use the signed-in SPMT session or OAuth access token. - Trusted server operations use a scoped, app-bound platform credential. - Existing users may be grandfathered only after immutable provider identity has been verified server-side. See `OAUTH_FLOW.md` and `../platform/IDENTITY.md`. ## 4. Use the SDK Prefer `@spmt/sdk` / `SpaceMountainClient` for shared contracts and authenticated requests. Typical modules include identity, apps, developer/shared surfaces, events, experience/XP, workspace, shared chat/Commlink, Athena, webhooks, game helpers, and Companion contracts. Do not hand-roll a second format when a versioned SDK/spec type already exists. ## 5. Request Minimum Permissions Ask only for capabilities the app actually uses. Keep privileged credentials server-side and test both allowed and forbidden operations. Examples of current platform scopes include identity, apps, messages, Athena, events, webhooks, and XP capabilities. See `../platform/PERMISSIONS.md` for the current public scope guidance. ## 6. Publish Events Instead of Hard-Coding App-to-App Calls Use the event bus when multiple consumers may care about an action. Events should have stable IDs, explicit source app, bounded payloads, and no raw secrets. Retries must be safe. If an operation changes a durable ledger such as XP, reuse the same stable upstream/idempotency identifier. ## 7. Use Commlink for User-Facing Communication When an app needs to surface messages, notifications, shared live-chat events, or operator actions, use Commlink contracts instead of creating another ecosystem-wide inbox. App-private chat/media state can remain app-owned; normalize cross-app data only at the shared boundary. ## 8. Use Athena Only for Real Context or Accepted Work Apps may write useful context or submit supported commands, but UI and API responses must distinguish configured, degraded, unavailable, and actually accepted/executed behavior. Do not document planned AI capability as if it is live. ## 9. Integrate Workspace/Shared Surfaces Only When Needed Apps that participate in the shared workspace should consume the versioned workspace profile/theme/surface contracts rather than copying UI preferences into unrelated schemas. Keep app-owned state separate from portable workspace preferences. ## 10. Test the Failure Paths Before calling an integration complete, test: - direct and embedded login; - logout and refresh; - account switching; - missing/revoked scopes; - invalid or replayed OAuth state/codes; - duplicate/retried events; - unavailable SPMT dependency; - tenant/account isolation; - health/version reporting; - restart/deploy persistence for app-owned durable state. ## Integration Checklist Every integrated app should: - use canonical SPMT identity; - avoid duplicate ecosystem profiles; - register app metadata and exact callbacks; - expose launch and health/version information; - use minimum scoped credentials; - publish shared events through platform contracts; - use Commlink for shared user-facing communication where appropriate; - write only useful, truthful Athena context; - use canonical XP/workspace/shared-surface contracts when participating in those systems; - have automated contract coverage plus a production smoke path for its critical integration. --- # Migrating An Existing App Into SpaceMountain ## Step 1: Identify duplicated platform logic Look for: - local login - fake identity - local notifications - local app launch assumptions - user profiles not tied to SPMT - platform account matching ## Step 2: Keep app-specific logic Do not move the app's core feature into SPMT. Examples: - game state stays in ChatTag - room state stays in HearMeOut - automation config stays in StreamWeaver - Discord-specific workflows stay in Discord Stream Hub ## Step 3: Add SPMT identity Use SPMT for current user identity and linked accounts. ## Step 4: Add event publishing Convert important app moments into ecosystem events. ## Step 5: Add Commlink outputs Only user-facing updates should appear in Commlink. ## Step 6: Add Athena summaries Summarize useful context. Do not dump raw logs. --- # OAuth Flow SPMT is the identity provider for first-party and future ecosystem apps. Apps should use the canonical SPMT account instead of creating a separate identity whenever SPMT identity is required. ## First-Party Authorization Code Flow ```mermaid sequenceDiagram participant User participant App participant SPMT User->>App: Open or connect app App->>SPMT: GET /api/oauth/authorize SPMT->>SPMT: Validate SPMT session, client, redirect URI SPMT-->>App: Redirect with one-time authorization code + state App->>SPMT: POST /api/oauth/token SPMT-->>App: Access token + refresh token App->>SPMT: GET /api/oauth/userinfo SPMT-->>App: Canonical SPMT identity ``` ### 1. Redirect to SPMT Send the browser to `/api/oauth/authorize` with the registered `client_id`, exact registered `redirect_uri`, and an application-generated `state` value. The user must already have, or establish, a valid SPMT session. SPMT returns the browser to the registered callback with the same `state` and a short-lived one-time authorization code. ### 2. Exchange the authorization code server-side The app backend exchanges the code at `POST /api/oauth/token` using: ```json { "grant_type": "authorization_code", "code": "one-time-code", "client_id": "your-app-id", "client_secret": "server-side-client-secret", "redirect_uri": "https://your-app.example/auth/spmt/callback" } ``` Authorization codes are one-time use. A replayed code is rejected. Client secrets must remain on the server. Do not embed a first-party OAuth client secret in browser JavaScript, desktop webviews, or public source bundles. ### 3. Read the canonical identity Use the returned access token with: ```http GET /api/oauth/userinfo Authorization: Bearer ``` The returned identity is the SPMT account the app should attach its local profile and app-owned state to. ### 4. Refresh without creating a second account The token response includes a refresh token for the app's server-side session lifecycle. Apps should refresh or re-authorize when needed rather than inventing a replacement local identity. ## Provider-Linked and Imported Accounts Twitch and Discord are linked providers, not competing account authorities. - Immutable provider user IDs are ownership evidence; display names and usernames are not. - Existing app users may be grandfathered into SPMT only through a trusted server-to-server path that has verified the provider identity. - Provider-owned/imported identities can later claim credentials without losing the canonical SPMT user ID. - Name collisions must not merge two people merely because their display names match. - Legacy app sessions may remain as compatibility paths during migration, but they must not silently grant new SPMT authority. The scoped SDK/server operation for trusted migrations is `client.identity.grandfather(...)`, backed by the app-bound platform identity contract. ## App Requirements - Use SPMT identity as the primary ecosystem identity. - Preserve and validate OAuth `state`. - Register exact callback URLs and reject unregistered redirects. - Exchange authorization codes from the backend. - Store sensitive tokens and client secrets server-side where practical. - Use linked provider IDs for Twitch/Discord attribution and matching. - Keep app-specific profiles optional and tied to the immutable SPMT user ID. - Handle logout, refresh failure, account switching, revoked credentials, and unavailable SPMT without creating duplicate users. - Request only the scopes the app actually needs. ## Verification The repository includes an end-to-end first-party OAuth regression test covering the registered SpaceMountain, Discord Stream Hub, StreamWeaver, ChatTag, HearMeOut, and MountainView clients. It verifies authorization, callback state, token exchange, userinfo identity, and one-time-code replay rejection against the canonical SPMT database. --- # SPMT SDK Specification Current package name: `@spmt/sdk` (with the `spmt` executable). ## Purpose The SDK should prevent every app from hand-rolling the same platform calls. ## Modules ### Identity ```ts client.identity.me() client.identity.refresh() ``` ### Apps ```ts client.apps.list() client.apps.get(appId) client.apps.install(appId) client.apps.disable(appId) ``` ### Events ```ts client.events.publish({ type: "reward.earned", sourceApp: "chat-tag", payload: {} }) ``` Backed by: - `POST /api/events` for user-session publishing - `POST /api/platform/events` for scoped platform API key publishing - `GET /api/platform/events` for server-side event history ### Commlink ```ts client.commlink.notify({ title: "Reward earned", body: "A viewer earned a reward.", sourceApp: "chat-tag" }) ``` ### Shared live chat Gate 3 begins with the exported `SharedChatEventV1` contract and validator. StreamWeaver remains the high-volume chat owner, but apps should normalize live Twitch, Discord, Kick, YouTube, Social Stream bridge, and app chat into this shape before SPMT indexes or displays it. ```ts import { validateSharedChatEventV1 } from "@spmt/sdk"; const result = validateSharedChatEventV1({ schemaVersion: 1, eventId: "evt_...", upstreamId: "twitch:message:...", tenantId: "tenant_...", platform: "twitch", sourceId: "stream_...", channelId: "channel_...", type: "message", sender: { id: "viewer_...", displayName: "Viewer" }, text: "hello chat", originalTimestamp: new Date().toISOString(), receivedTimestamp: new Date().toISOString() }); ``` Required ownership boundaries: - `tenantId`, `sourceId`, and `channelId` are routing identifiers, not display names. - `eventId` is the SPMT/StreamWeaver stable ID; `upstreamId` is the provider message/event ID. - `routing.canReply`, `routing.botReadable`, and `routing.botCanReply` must be explicit before UI or bots expose reply controls. - Mail/direct messages and live chat remain different data types even when shown in the same Commlink workspace. ### Shared XP ledger Gate 1 uses SPMT as the canonical XP/level/reward ledger. Apps should publish bounded, idempotent awards through `client.experience.award(...)` or build a known award with `mappedXpAwardV1(...)`. ```ts import { mappedXpAwardV1, validateXpAwardV1 } from "@spmt/sdk"; const award = mappedXpAwardV1({ userId: "spmt_user_id", mappedEventType: "chat-tag.tag", upstreamEventId: "twitch:message:123", metadata: { tenantId: "creator_tenant", channelId: "twitch_channel" }, }); if (validateXpAwardV1(award).ok) { await client.experience.award(award); } ``` Current canonical mappings: - `chat-tag.tag` -> `chat-tag` / `chat-tag-tag`, +100 XP - `chat-tag.pass` -> `chat-tag` / `chat-tag-pass`, +200 XP - `chat-tag.bingo.square` -> `chat-tag` / `chat-tag-bingo-square`, +10 XP - `chat-tag.bingo.win` -> `chat-tag` / `chat-tag-bingo-win`, +250 XP - `dsh.discord.message` -> `discord-stream-hub` / `dsh-discord-message`, +1 XP - `dsh.twitch.message` -> `discord-stream-hub` / `dsh-twitch-message`, +10 XP - `dsh.twitch.follow` -> `discord-stream-hub` / `dsh-twitch-follow`, +25 XP - `dsh.twitch.raid` -> `discord-stream-hub` / `dsh-twitch-raid`, +50 XP - `dsh.twitch.sub` -> `discord-stream-hub` / `dsh-twitch-sub`, +100 XP - `spacemountain.tool.trigger` -> `spacemountain` / `spacemountain-tool-trigger`, +5 XP - `spacemountain.arena.kill` -> `spacemountain` / `spacemountain-arena-kill`, +1 XP Every producer must supply the immutable SPMT `userId`, a stable upstream event/message ID, and metadata that identifies tenant/source/channel without storing secrets. Retries must reuse the same idempotency key so points cannot be awarded twice. ### Athena ```ts client.athena.remember({ topic: "Stream summary", content: "StreamWeaver completed 3 automations." }) ``` ### Webhooks ```ts client.webhooks.create({ url: "https://example.com/webhook", events: ["reward.earned"] }) ``` ## SDK Principles - Make the safe path easy. - Hide token/header details where possible. - Keep app-specific logic out of the SDK. - Keep response shapes predictable. - Provide browser and server usage modes separately. --- # SDK Guide Current package: `@spmt/sdk` with the `spmt` command. The source implementation lives at `sdk/index.ts`. The SDK is no longer only a suggested direction: it contains the shared client, validators, versioned contracts, and helpers used by current integration work. ## Create a Client ```ts import { SpaceMountainClient } from '@spmt/sdk'; const spmt = new SpaceMountainClient({ baseUrl: 'https://spmt.live', appId: 'your-app-id', token: () => currentUserToken, }); ``` Use `token` for user/session calls. For trusted server-to-server operations, create the client with an app-bound `apiKey` and keep that credential on the server. ## Current Areas The SDK currently exposes contracts/helpers across these areas: - identity and imported-account migration; - apps / Shipyard; - developer components and shared surfaces; - events; - game event helpers; - canonical experience / XP; - workspace profiles, theme tokens, and overlay workspace data; - shared live-chat normalization; - Commlink dispatch/operator/integration contracts; - Athena context/commands; - webhooks; - Companion devices, capabilities, and commands; - shared versioned types and validators. Not every conceptual platform feature has a mature helper yet. Check `SDK_SPEC.md`, the exported types in `sdk/index.ts`, and the relevant platform spec before depending on a contract. ## Identity ```ts const me = await spmt.identity.me(); ``` Server integrations can use scoped identity operations such as verified grandfathering when they hold the correct app-bound permission. ## Workspace ```ts const { profile } = await spmt.workspace.profile(); ``` Workspace writes are revision-aware. Use SDK helpers instead of writing a second preference schema. ## Experience / XP ```ts const balance = await spmt.experience.balance(); ``` Trusted producers award XP through the scoped server client and an idempotent `XpAwardV1` payload. ## Events ```ts await spmt.events.publish({ type: 'automation.completed', sourceApp: 'your-app-id', payload: { automationId: 'auto_123' }, }); ``` Choose the user-session or server credential client based on who owns the action. ## Goal Apps should not hand-roll SPMT API calls or invent competing versions of shared contracts. The SDK should make the safe, versioned path the easiest path while keeping app-specific logic in the owning app. --- # API Examples These examples show current SPMT integration patterns. Prefer `@spmt/sdk` in application code and use raw HTTP mainly for debugging or integrations that cannot use the SDK. Current SPMT public base: `https://spmt.live` Current snapshot: `2026-09-11T18:18:41.026Z` ## Get Current User ```bash curl https://spmt.live/api/me \ -H "Authorization: Bearer $SPMT_TOKEN" ``` ## OAuth Userinfo After an app exchanges its authorization code for an access token: ```bash curl https://spmt.live/api/oauth/userinfo \ -H "Authorization: Bearer $SPMT_OAUTH_ACCESS_TOKEN" ``` ## List Apps ```bash curl https://spmt.live/api/apps \ -H "Authorization: Bearer $SPMT_TOKEN" ``` ## Install App ```bash curl -X POST https://spmt.live/api/apps/chat-tag/install \ -H "Authorization: Bearer $SPMT_TOKEN" ``` ## Read Workspace Profile ```ts const { profile } = await spmt.workspace.profile(); console.log(profile.revision, profile.appearance.themeId); ``` Workspace writes are revision-aware; use the SDK patch/replace helpers rather than blind overwrites. ## Publish A User Event ```ts await spmt.events.publish({ type: 'automation.completed', sourceApp: 'streamweaver', payload: { automationId: 'auto_123', summary: 'Scene switch automation completed.' } }); ``` ## Award Canonical XP From A Trusted Server ```ts import { mappedXpAwardV1, SpaceMountainClient } from '@spmt/sdk'; const serverSpmt = new SpaceMountainClient({ baseUrl: 'https://spmt.live', appId: 'discord-stream-hub', apiKey: process.env.SPMT_API_KEY, }); await serverSpmt.experience.award(mappedXpAwardV1({ userId: 'spmt-user-id', mappedEventType: 'dsh.discord.message', upstreamEventId: 'discord:message:123', metadata: { tenantId: 'creator-tenant', channelId: 'discord-channel-id' }, })); ``` The platform credential stays server-side. Retries must reuse the same stable upstream event ID. ## Send A Commlink Notification ```ts await spmt.commlink.notify({ title: 'Automation completed', body: 'StreamWeaver completed your intro scene workflow.', sourceApp: 'streamweaver' }); ``` ## Write Athena Context ```ts await spmt.athena.remember({ topic: 'Stream automation', content: 'Intro scene automation completed successfully.', sourceApp: 'streamweaver' }); ``` ## Register A Webhook ```ts await spmt.webhooks.create({ url: 'https://example.com/spmt-webhook', events: ['automation.completed'] }); ``` Webhook URLs must use HTTPS. --- # Webhooks Webhooks let signed-in developers register HTTPS destinations for selected SPMT ecosystem events. ## Current Developer Routes - `GET /api/platform/webhooks` — list the current developer's registered webhooks. - `POST /api/platform/webhooks` — create a webhook registration. Creation requires an HTTPS URL. The SDK exposes the same create operation through `client.webhooks.create(...)`. ## Example ```ts await spmt.webhooks.create({ url: 'https://example.com/spmt-webhook', events: ['automation.completed', 'app.installed'] }); ``` ## Webhook Use Cases - send an ecosystem event to an external dashboard; - trigger an integration workflow from an SPMT event; - notify another trusted system that an app or room changed state; - feed analytics or operational tooling without hard-coding one app directly to another. ## Event Shape Consumers should treat event IDs, type, source app, timestamp, actor, visibility, links, and payload as bounded platform data. Exact event contracts should come from the event catalog/spec when one exists. Example: ```json { "id": "evt_123", "type": "voice.room.created", "sourceApp": "hearmeout", "timestamp": "2026-07-04T12:00:00Z", "actor": { "userId": "user_123" }, "payload": { "roomId": "room_456", "title": "Watch Party" } } ``` ## Reliability Rules - Use HTTPS webhook destinations. - Include and persist event IDs. - Make consumers idempotent because delivery or upstream work may be retried. - Never include raw secrets, credentials, or private internal logs in payloads. - Prefer stable object/provider IDs over display names. - Return failures visibly in operational tooling; do not silently treat failed delivery as success. - Keep webhook-side authorization independent from any SPMT credential that created the registration. ## Scope Boundary Webhook registration is a developer/platform integration surface. It does not make an external endpoint a trusted SPMT server credential and does not grant that receiver permission to call privileged platform APIs. --- # Plugin Guide A plugin should extend the ecosystem without replacing platform services. ## Plugin Requirements - register with SPMT - declare permissions - publish ecosystem events - expose version metadata - avoid duplicating identity and messaging ## Good Plugin Examples - Athena brief generator - Stream snapshot exporter - Webhook relay - Crew routing assistant --- # Testing Guide ## Manual Smoke Test 1. Open SpaceMountain.live. 2. Open Docs. 3. Open Shipyard. 4. Open Commlink. 5. Confirm app list loads. 6. Launch a registered app. 7. Confirm SPMT identity is restored where supported. 8. Trigger or fake an app event. 9. Confirm notification or Commlink output appears. ## App Integration Test For each app: - Can it launch from Shipyard? - Does it know the SPMT user? - Does it publish at least one event? - Does it avoid duplicate identity? - Does it expose health/version metadata? ## Docs Test - Docs nav loads. - Docs search filters. - Markdown content renders. - Diagrams remain readable. - Links point to existing files. --- # Release Notes Template ## Version `vX.Y.Z` ## Summary One or two sentences explaining what changed. ## Added - New features ## Changed - Behavior changes ## Fixed - Bug fixes ## Docs - Documentation updates ## Migration Notes - Anything developers or users need to update ## Verification - Build result - Live check - Known limitations --- # Style Guide ## Terminology - SPMT = Creator Cloud - SpaceMountain.live = Command Bridge - Athena = Operating Intelligence - Shipyard = App Lifecycle Manager - Commlink = Communication Hub - Event Bus = Cross-app integration layer ## Voice Clear, confident, creator-first, slightly cosmic, never vague. ## Engineering Rule Do not duplicate shared platform services inside apps. --- ## Examples # Example: First Ecosystem App Imagine an app called `ClipForge`. ## What ClipForge Does ClipForge turns stream moments into shareable clips. ## App Metadata ```json { "id": "clipforge", "name": "ClipForge", "description": "Turn stream moments into shareable clips.", "launchUrl": "https://clipforge.example.com", "version": "0.1.0", "scopes": ["identity:read", "events:write", "messages:write"] } ``` ## Events ClipForge publishes: - `clip.created` - `clip.ready` - `clip.failed` ## Commlink Example When a clip finishes: > ClipForge finished your stream highlight and it is ready to share. ## Athena Example Athena can later say: > ClipForge created three clips during your last stream. --- # End-To-End Example: Stream Night ## Scenario The creator starts a stream. ## Flow 1. StreamWeaver publishes `stream.started`. 2. Discord Stream Hub publishes `discord.shoutout.created` for live partners. 3. ChatTag publishes `game.started`. 4. HearMeOut publishes `voice.room.created`. 5. SPMT routes events to Commlink, Athena, and notifications. 6. SpaceMountain.live shows a workspace summary. 7. Athena explains what is happening. ## Athena Summary > Stream is live. StreamWeaver has automations ready, Discord Stream Hub found two partners live, ChatTag started a reward game, and HearMeOut has a voice room open. ## Why This Matters No individual app can provide that summary alone. The ecosystem can. --- ## Launch # Launch Plan ## Goal Introduce SpaceMountain as a connected creator operating system, not a collection of streamer tools. ## Launch Message > One identity. One command bridge. Every creator tool connected. ## Launch Phases ### Phase 1: Private Builder Preview Audience: - trusted creator friends - small streamers - moderators - developer friends Goal: - validate identity flow - validate Shipyard - validate Commlink - validate app launches - collect screenshots and quotes ### Phase 2: Creator Alpha Audience: - streamers who already use multiple tools - creators with Discord communities - streamers who run events, games, rooms, or automations Goal: - prove the ecosystem saves time - demonstrate real integrations - test app install and notifications ### Phase 3: Developer Preview Audience: - bot builders - overlay builders - creator tool developers - plugin developers Goal: - validate SDK direction - validate app submission flow - validate event bus model - collect feedback on APIs ### Phase 4: Public Story Launch Audience: - creators - communities - indie devs - streamer tool users Goal: - explain the vision - drive signups - invite app builders - share demos --- # Launch Checklist ## Product - SPMT account creation works. - SpaceMountain.live loads reliably. - Shipyard shows apps. - Commlink opens. - Athena surface is visible. - Docs page opens. - Core apps have launch URLs. - Broken or planned features are labeled clearly. ## Content - README explains the project. - Docs home explains where to start. - Website copy is ready. - FAQ is ready. - App integration guide is ready. - Screenshots or placeholders exist. - Social posts are drafted. ## Trust - Do not overclaim features. - Clearly label MVP, alpha, planned, and experimental surfaces. - Explain privacy and identity expectations. - Tell users what is working now versus what is next. ## Demo Demo path: 1. Create or sign into SPMT. 2. Open SpaceMountain.live. 3. Open Shipyard. 4. Launch an app. 5. Show Commlink. 6. Ask Athena for an ecosystem summary. 7. Explain how another app plugs in. --- ## Support # User Support ## Common Issues ### I signed in but an app does not know who I am Try: 1. Refresh SpaceMountain.live. 2. Open the app from Shipyard. 3. Sign into SPMT again. 4. Report which app failed. ### An app says it is installed but will not launch Check: - launch URL - app health - whether the app is enabled - whether the app is still in adapter-needed status ### Notifications are missing Check: - whether the app publishes Commlink events - whether the notification is user-facing - whether the user is signed into SPMT ## Reporting Bugs Include: - app name - page URL - what you expected - what happened - whether you were signed into SPMT - screenshot if possible ## Planned Unified Ticket Intake The unified SPMT ticket system is roadmap work and must not be described as live until production verification is complete. The target is one intake path for general help, app/technical issues, staff reports, warnings/infractions, disputes/appeals, account/billing questions, and security/privacy/safety issues. The provisional `!ticket` command will remove the public command where the provider permits it, show a `Ticket` interaction button, and open an ephemeral chooser and structured modal. Existing SPMT support concepts and `!mtfixit` will route into the same ticket record rather than creating separate queues. Each submitted ticket will receive an ID, a private status view, and a bounded, redacted evidence snapshot from relevant registered apps. Staff can escalate to moderators, moderators to administrators, and administrators to the owner or co-owner. Sensitive evidence will remain in the authenticated ticket record; DMs and other notifications will contain only a safe summary and secure link. Implementation requirements, privacy limits, role authority, retention, appeals, and production proof are owned by [`docs/ecosystem/PRODUCTION_ROADMAP.md`](../ecosystem/PRODUCTION_ROADMAP.md#step-36--unify-support-staff-reports-disputes-and-technical-tickets). --- # Known Limitations SpaceMountain is evolving quickly. Public documentation should distinguish implemented contracts, production-verified behavior, and planned work. ## Current Areas To Label Clearly - First-party apps have SPMT identity/OAuth paths, but the full two-account live matrix for direct/embedded login, logout, refresh, account switching, disconnect/export/deletion remains production verification work. - Some app integrations still have app-specific adapters or compatibility paths while canonical SPMT identity, XP, shared chat, and workspace contracts converge. - Athena exposes real shared memory/context and configured platform surfaces, but several assistant/automation/voice capabilities remain unavailable or planned and must not be presented as executed behavior. - The SDK is a real repository implementation with generated package output and versioned contracts; consumers should still verify the specific exported helper/contract they depend on rather than assuming every platform idea has an SDK method. - The docs UI is intentionally lightweight. It renders common Markdown constructs itself rather than using a full documentation framework. - Mermaid source is preserved in documentation/code blocks, but the lightweight docs page does not yet provide a full Mermaid diagram renderer. - The complete `SPMT-DOCS.md` download is generated from the public navigation manifest during the production image build. It contains the public documentation set, not internal production/archive material. - Some production gates remain open even when a route, UI, build, or test exists. Production readiness requires the live evidence and failure/recovery behavior defined by the authoritative production roadmap. ## Rule Do not hide limitations or turn roadmap intent into present-tense capability. Update this page when a limitation is actually removed, and keep detailed engineering status in the authoritative production roadmap rather than duplicating the active backlog here. --- ## Business # Positioning SpaceMountain is the creator operating system. It is not another streamer utility. It is a connected workspace where creator tools share identity, communication, events, and AI context. ## Primary Audiences - streamers - VTubers - community managers - moderators - creator developers - small creator teams ## Core Value Every connected app becomes more useful because it shares identity, events, communication, and AI context. --- # Website Structure ## Home Sections: 1. Hero 2. Problem 3. Solution 4. Creator Cloud 5. Command Bridge 6. Shipyard 7. Commlink 8. Athena 9. Ecosystem Apps 10. Developer Platform 11. FAQ 12. Call To Action ## Hero Headline: One Identity. One Command Bridge. Every Creator Tool Connected. Subheadline: SpaceMountain connects streamer tools, community apps, AI, notifications, and automation into one creator operating system. Primary CTA: Enter the Command Bridge Secondary CTA: Read the Docs ## Problem Creators are drowning in disconnected dashboards. ## Solution SPMT connects identity, apps, events, messages, and AI into one ecosystem. ## Proof Show real ecosystem examples: - ChatTag reward becomes Commlink notification. - HearMeOut room invite appears in Command Bridge. - StreamWeaver automation can be summarized by Athena. - Discord Stream Hub shoutout becomes a cross-app event. --- # Website Copy ## Hero # One Identity. One Command Bridge. One Creator Ecosystem. Stop juggling disconnected dashboards. SpaceMountain connects your creator tools into one intelligent workspace powered by SPMT. ## Sections ### Creator Cloud One `@spmt.live` account powers every connected app. ### Command Bridge Launch apps, manage notifications, conversations, and your creator workflow from one place. ### Athena An AI that understands your ecosystem, not just your prompts. ### Shipyard Install and launch apps without creating new accounts. ### Commlink One inbox for messages, app events, AI updates, and community activity. --- # Go-To-Market Plan ## Target Users ### Primary Streamers and creators who already juggle multiple tools. They feel pain from: - too many dashboards - scattered notifications - disconnected community identity - bot/app setup fatigue - no single view of what happened ### Secondary Creator tool developers who do not want to rebuild identity, messaging, and app discovery. ## Product Category SpaceMountain should be positioned as a creator operating system. Not: - a bot - a dashboard - a Discord tool - a streamer utility bundle But: - a connected creator workspace - a platform for creator apps - an operating layer for streaming and community tools ## Adoption Hooks - One login for connected apps. - One place to launch tools. - One inbox for app and community updates. - One AI that understands the ecosystem. - Apps that become more valuable together. ## Community-Led Growth Early growth should come from demos, creator workflows, and visible integrations. Best demos: - Stream night summary - ChatTag reward triggering a notification and overlay - HearMeOut invite appearing in Commlink - Discord shoutout appearing in Command Bridge - Athena summarizing app activity --- # Marketing ## One-Liner SpaceMountain is the creator operating system for streamers, communities, and connected live tools. ## Short Pitch Creators use too many disconnected dashboards. SpaceMountain gives them one identity, one command bridge, one AI, one app launcher, and one communication hub. ## Taglines - Stop managing tools. Start commanding your ecosystem. - One identity. Every creator tool connected. - The creator operating system for streamers and communities. - Where your creator tools become one ecosystem. ## Why Adopt - fewer accounts - fewer dashboards - unified notifications - connected AI - shared community identity - easier app discovery - better developer platform --- # Social Posts ## Announcement SpaceMountain is becoming a creator operating system. One identity. One command bridge. One AI. One app launcher. One communications hub. Streamer tools should not feel like disconnected islands anymore. ## Creator Pain Post How many dashboards does your stream setup require? Bot dashboard. Discord tools. Overlay tools. Music tools. Game tools. AI tools. Community tools. SpaceMountain is built around one idea: your tools should work together. ## Developer Post Building creator tools? SPMT is designed to give apps shared identity, app registry, Commlink notifications, Athena context, events, and future SDK support. Build the app. Do not rebuild the platform. ## Athena Post Athena is not just another chatbot. The goal is an AI that understands your creator ecosystem: apps, rooms, rewards, notifications, automations, and community activity. That is operating intelligence. --- # Elevator Pitch SpaceMountain is the creator operating system. SPMT provides the Creator Cloud: identity, app registry, communication, APIs, and shared intelligence. SpaceMountain.live is the Command Bridge where creators launch apps, manage communities, receive notifications, and work alongside Athena. Instead of isolated streamer tools, every app benefits from shared identity, shared events, shared AI, and a unified creator workspace. --- # Pitch Deck Outline ## Slide 1: Title SpaceMountain The Creator Operating System ## Slide 2: Problem Creators use too many disconnected tools. ## Slide 3: Insight The tools are not the problem. The disconnection is. ## Slide 4: Solution One identity, one command bridge, one AI, one app ecosystem. ## Slide 5: Product SPMT Creator Cloud + SpaceMountain Command Bridge + ecosystem apps. ## Slide 6: Live Examples - StreamWeaver automation - Discord Stream Hub shoutouts - HearMeOut rooms - ChatTag rewards - Athena summaries ## Slide 7: Platform Identity, Shipyard, Commlink, Event Bus, Athena, APIs, Plugins. ## Slide 8: Why Now Creators increasingly rely on AI, automation, community tools, and multi-platform workflows. ## Slide 9: Developer Opportunity Build once. Integrate with the ecosystem. ## Slide 10: Roadmap Alpha, creator preview, developer preview, plugin marketplace, SDK. ## Slide 11: Ask Creators: try it. Developers: build on it. Communities: help shape it. --- # Brand ## Core Message Stop managing tools. Start commanding your ecosystem. ## Product Terms - SPMT: Creator Cloud - SpaceMountain.live: Command Bridge - Athena: Operating Intelligence - Shipyard: App Lifecycle Manager - Commlink: Communication Hub - Event Bus: Cross-App Integration Layer ## Tone - ambitious - clear - helpful - creator-first - cosmic without being confusing --- ## Community Terms # SpaceMountain.Live Community Terms Package Status: **Owner-approved final draft - effective only after publication and acceptance** Version: `1.0` Prepared: 2026-08-02 Administrative home and proposed governing law: Illinois, United States This directory contains the approved operational draft for SpaceMountain.Live's three participant classes: 1. [Partner Community Terms](PARTNER_COMMUNITY_TERMS.md) 2. [Crew and Administrator Community Terms](CREW_ADMINISTRATOR_COMMUNITY_TERMS.md) 3. [Developer and SDK Community Terms](DEVELOPER_SDK_COMMUNITY_TERMS.md) 4. [Shared Electronic Acceptance Schedule](ELECTRONIC_ACCEPTANCE_SCHEDULE.md) These files record the Owner-approved participation model. They are not legal advice, do not themselves appoint anyone, and become effective for a person only after publication, role approval, and affirmative acceptance through the SPMT acceptance flow. ## Confirmed organization facts - The ecosystem and community are known as **SpaceMountain.Live**, and may also be described as **SpaceMountain**, **SPMT**, or **spmt.live**. - `mtman1987` is the **Owner**. - `akhiteddy` is the **Co-Owner**. - A proxy has authority only when a dated written delegation states its scope, duration, limits, and approving Owner or Co-Owner. - Community members may be called **Mountaineers**. - **Crew** is the umbrella for recognized human staff roles. The working hierarchy is Administrator, Moderator, then Staff. Owner, Co-Owner, and a written proxy are governance authorities, not ordinary Crew ranks. - Partner and Administrator are mutually exclusive primary roles. A Partner may hold Staff or Moderator status only through a separate written Crew appointment. A Partner, Crew member, or Administrator may separately accept Developer and SDK terms. - Participants use named SPMT identities for official activity. Shared credentials are prohibited. An `@spmt.live` identity is not promised to be an email mailbox unless a mailbox is separately provisioned. - Electronic acceptance uses an authenticated SPMT session and the button text **Accept Community Terms**. OAuth authenticates the account; a separate affirmative action supplies assent. ## Ecosystem ownership map The following first-party services and applications are owner-owned and operated as parts of the SpaceMountain.Live ecosystem: - SPMT / Creator Cloud, including identity, Shipyard, Commlink, Athena OS, ecosystem events, shared XP, platform APIs, documentation, `@spmt/sdk`, and the `spmt` CLI. - SpaceMountain / Command Bridge and SpaceMountain Companion. - StreamWeaver. - Discord Stream Hub. - HearMeOut and the HearMeOut DJ Worker. - ChatTag. - Quackverse, while and to the extent it remains an offered service. - Fly Machine Rotator and MountainView. - The archived Space Mountain dashboard, which is owner-owned but retired and is not an active service. **AETHERRA is the exception.** It is separately owned and operated by Co-Owner `akhiteddy`. It is an external partner application and remains responsible for its product code, product data, billing, deployment, backups, and operations unless a signed addendum says otherwise. Its possible use of SPMT identity, events, SDK, or other services does not transfer ownership to SPMT. Future owner-operated applications become covered after notice. A material new duty, payment term, data use, IP grant, or dispute term requires affirmative acceptance of a revised document or addendum. ## Relationship and benefit decisions - Community participation is intended to be voluntary and non-exclusive. It creates no agency, legal partnership, authority to bind SPMT, or guaranteed compensation. - No hours, quotas, mandatory shifts, or guaranteed future paid work are created by these documents. - Administrators currently may receive five gifted Twitch subscriptions to their own channels in most months when ownership can afford the out-of-pocket cost. This appreciation practice is discretionary, may be skipped, paused, changed, or ended, never accrues, and is not transferable or cash-redeemable. - Crew and Partners may receive complimentary premium access across SPMT apps. Access is discretionary, personal, non-transferable, subject to availability, and normally ends immediately when the qualifying role is suspended or ends. - Crew receives first priority consideration for databases, technology, applications, and technical beta access; Partners receive second priority. - Partners receive first priority consideration for exclusive content and studio-partner opportunities; Crew receives second priority. - Priority means early notice or priority consideration, not guaranteed access. Third-party studios and providers may set independent eligibility, NDA, embargo, availability, and withdrawal rules. - Future formal payments require a separate written arrangement. The planned SPMT payment experience may route approved payouts to a linked account through PayPal; PayPal operates the payment rails. Until that flow is verified live, no embedded-payment capability is promised. ## Governance decisions - Any recognized Crew member may create a documented warning. - A Staff warning receives Moderator review. A Moderator warning receives Administrator review. Material findings normally proceed to ownership. - Administrators may investigate and may take the narrow temporary actions described in the Crew terms. Moderators do not gain suspension authority unless a separate written delegation grants it. - Active, uninvolved recognized Crew may submit one blind advisory vote in an internal review. Votes are visible only to ownership or the authorized decision-maker. They do not bind ownership, and a tie has no automatic effect. - Final ordinary authority remains with the Owner, Co-Owner, or a written proxy acting within its delegation. - A conflicted decision-maker must recuse. A complaint concerning the Owner or Co-Owner must be routed to the other unconflicted owner or a conflict-free written proxy; the subject may not be the sole reviewer. - A participant offered a written-statement opportunity normally has seven days. Submission is optional, and declining alone is not grounds for action. - A participant normally has 14 days after a final ownership decision to use the single formal appeal. Significant new evidence, fraud, or serious process error may justify reopening outside that appeal. - Emergency Administrator action must be documented and reported to ownership within 24 hours. It expires after 72 hours unless ownership continues, changes, or ends it. ## Record decisions - Ordinary warning records remain for the life of the applicable role or accepted terms. - Major infractions, Administrator interventions, emergency actions, and owner decisions are retained for the maximum period permitted by applicable law and migrated to a secure archive if a system is retired. - Participants may request a redacted copy of their own record and correction of objectively false facts. Confidential deliberations, security information, privileged material, and other people's personal data may be withheld. - Evidence capture is relevant and proportionate. It may include the reported event, ten preceding and ten following messages where available, app/version, surface, health, timestamps, and correlated audit events. It must not sweep entire databases, unrelated private conversations, credentials, secrets, or unnecessary payment data. ## Ownership activation checklist Before these terms become live, ownership must: 1. Publish SpaceMountain.Live as an owner-operated project controlled by `mtman1987`, with Illinois as its administrative home and governing law. 2. Publish the privacy notice, retention schedule, copyright/DMCA contact, security contact, and interim support/ticket channel. 3. Keep SDK access approval-only under the Developer and SDK Community Terms; do not describe the package as open source while its metadata remains `UNLICENSED`. 4. Verify the SPMT acceptance implementation against the acceptance schedule, including downloadable records, attribution, correction, versioning, retention, and reacceptance. 5. Pause and reassess any role that begins to function like required employment or paid contracting. These terms do not waive compensation or worker-status rights imposed by law. The labor-classification guardrail remains essential. U.S. Department of Labor guidance states that employees may not volunteer services to private for-profit employers. Labels in a community document do not decide legal status. See the [U.S. Department of Labor FLSA Advisor](https://webapps.dol.gov/elaws/whd/flsa/docs/volunteers.asp). Illinois's current Uniform Electronic Transactions Act recognizes electronic records and signatures, but it also emphasizes agreement to transact electronically, intent, attribution, retainable records, and correction of automated errors. See [Illinois Public Act 102-0038](https://www.ilga.gov/documents/legislation/PublicActs/102/102-0038.htm) and the federal [Electronic Signatures in Global and National Commerce Act](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section7001&num=0&edition=prelim). ## Document authority After owner publication and participant acceptance, the accepted version and hash of each role document govern that participant's role. The production roadmap owns implementation work. Technical specifications describe platform behavior and do not silently amend accepted Community Terms. --- # SpaceMountain.Live Partner Community Terms Status: **Owner-approved final draft - effective only after publication and acceptance** Version: `1.0` Prepared: 2026-08-02 Proposed governing law: Illinois, United States These Partner Community Terms (the **Terms**) describe participation as a recognized SpaceMountain.Live Partner. They become effective for a Partner only after owner publication, role approval, assignment of an effective date, and affirmative acceptance under the [Electronic Acceptance Schedule](ELECTRONIC_ACCEPTANCE_SCHEDULE.md). ## 1. Parties and purpose **SpaceMountain.Live** means the owner-operated project and ecosystem also known as SpaceMountain, SPMT, or spmt.live. `mtman1987` acts as Owner and `akhiteddy` as Co-Owner. Illinois is the project's administrative home and the proposed governing law for these Terms. **Partner** means the individual SPMT account holder approved for Partner participation. Partner status is personal even when the individual serves as a liaison for an outside channel, community, organization, or business. These Terms support voluntary community collaboration, cross-promotion, creator opportunities, and access to selected SPMT resources. They do not make the Partner's outside community a party and do not authorize the Partner to bind that community or SpaceMountain.Live. ## 2. Covered ecosystem The current first-party ecosystem includes SPMT/Creator Cloud, SpaceMountain, Shipyard, Commlink, Athena OS, StreamWeaver, Discord Stream Hub, HearMeOut and its DJ Worker, ChatTag, Quackverse while offered, Fly Machine Rotator, MountainView, SpaceMountain Companion, the platform APIs, `@spmt/sdk`, and the `spmt` CLI. These applications and services are owner-owned and operated. AETHERRA is separately owned and operated by Co-Owner `akhiteddy` as an external partner application. AETHERRA's participation in SPMT does not make it owner-operated or transfer its code, data, billing, deployment, or operations to SpaceMountain.Live. Future owner-operated services become covered after reasonable notice. A material new duty, payment term, data use, IP grant, dispute term, or other material change requires affirmative acceptance of a revised document or addendum. ## 3. Definitions - **Mountaineer**: a member of the wider SpaceMountain.Live community. - **Crew**: recognized human staff, including Staff, Moderators, and Administrators. - **Ownership**: the Owner, Co-Owner, or a written proxy acting within a dated delegation. - **Official Account**: the named SPMT identity assigned or approved for official participation. An `@spmt.live` identity is not necessarily an email mailbox. - **Outside Community**: the channel, server, organization, business, or group a Partner represents but that is not a party to these Terms. - **Community Rules**: the current acceptable-use, conduct, privacy, security, brand, event, and platform rules incorporated by a versioned acceptance record. - **Major Infraction**: a serious or potentially damaging event, including credible harassment, threats, fraud, exploitation, impersonation, material security/privacy misconduct, or deliberate platform/reward manipulation. ## 4. Eligibility, application, and appointment The Partner must be at least 18 years old, hold a named SPMT account, provide accurate application information, disclose material conflicts, and have the rights needed for submitted names, branding, content, and links. SPMT records the application, time in each state, eligible reviewers, blind advisory votes, recusals, ownership decision, notices, offered document version, and acceptance. All active, uninvolved recognized Crew may vote. Votes are advisory; a majority or tie does not bind ownership. Approval is not active until the Partner accepts these Terms and completes any role-specific onboarding. Ownership may deny an application in good faith and is not required to publish confidential deliberations. ## 5. Personal and liaison status The Partner accepts these Terms personally. If representing an Outside Community, the Partner must: - accurately identify that community and the Partner's authority within it; - communicate applicable SPMT requirements to people participating through the relationship; - avoid implying that the Outside Community has signed these Terms; - remain responsible for the Partner's own statements and submissions; and - promptly notify ownership if the Partner no longer owns, controls, or represents that community. Loss of the representative relationship triggers immediate review and may pause or end Partner status. The Partner may not make legal, payment, policy, employment, sponsorship, refund, product, or support commitments for SPMT. ## 6. Relationship; no employment, agency, or legal partnership Participation is optional, unpaid, and non-exclusive. These Terms do not require hours, shifts, quotas, minimum streams, referrals, appearances, or continued availability. They do not create employment, independent-contractor status, agency, fiduciary status, franchise, joint venture, or a legal partnership. The Partner controls the Partner's channels, business, staff, sponsors, content, taxes, and third-party accounts. The word **Partner** is a community designation only and does not authorize either party to bind the other. Nothing in these Terms waives compensation, worker-status, or other rights that cannot lawfully be waived. If actual activities become required work or create a paid or otherwise regulated relationship, those activities must pause until ownership issues a separate written arrangement appropriate to that relationship. ## 7. Partner responsibilities The Partner agrees to: - act honestly, respectfully, and without harassment, retaliation, discrimination, exploitation, fraud, or impersonation; - follow applicable law, Community Rules, and Twitch, Discord, YouTube, PayPal, LiveKit, GitHub, hosting, studio, and other provider terms; - describe SPMT features and the relationship truthfully, including degraded, experimental, planned, changed, or retired capabilities; - disclose material sponsorships, conflicts, and outside restrictions; - protect minors and vulnerable community members under applicable rules; - use rewards, points, XP, games, prizes, and promotional systems honestly; - use the approved ticket path for help, reports, disputes, and appeals; and - cooperate reasonably with a proportionate investigation while preserving the right to decline an optional written statement without punishment for the refusal alone. ## 8. Authority and limitations Partner status does not grant moderation, Administrator, payment, contracting, developer, source-code, database, private-log, or credential authority. Partner and Administrator are mutually exclusive primary roles. A Partner may be appointed as Staff or Moderator only through a separate written Crew appointment and separate acceptance. A Partner may separately become a Developer or SDK user after accepting the Developer and SDK Community Terms. Only approved brand assets and language may be used. The Partner may not: - alter SPMT marks or create confusing domains, accounts, merchandise, or endorsements; - claim to be an owner, officer, employee, agent, attorney, spokesperson, or payment representative of SpaceMountain.Live; - grant another person Partner access or share an Official Account; - promise benefits, priority, prizes, compensation, refunds, integrations, availability, or support on SPMT's behalf; or - access or use nonpublic information beyond the granted purpose. ## 9. Discretionary benefits and priorities While active and in good standing, a Partner may receive: - complimentary premium access to available SPMT applications; - SPMT resources and approved promotional capabilities supporting the Partner's community; - directory placement, specialized shoutouts, spotlights, event promotion, approved application links, or co-branded materials when offered; - second-priority consideration for databases, technology, applications, and technical beta access; and - first-priority consideration for exclusive content and studio-partner opportunities. Benefits are discretionary, personal, revocable, non-transferable, not cash-redeemable, and do not accrue. Priority means early notice or priority consideration, not guaranteed admission. Capacity, safety, law, technical readiness, ownership judgment, and third-party studio/provider rules control. Separate confidentiality, embargo, testing, or content terms may apply. Benefits may pause during investigation or suspension and normally end immediately when Partner status ends. The Administrator five-gifted-subscription practice does not apply to Partners unless a separate writing says so. ## 10. Official accounts, access, and security Official activity must use the Partner's named account. SPMT retains administrative recovery control over an assigned SPMT-owned account and may monitor official-system activity after notice for security, support, compliance, and audit purposes. The Partner must use unique credentials and available multi-factor authentication, keep tokens and recovery information secret, report suspected compromise promptly, and never share accounts, cookies, keys, private exports, or credentials. Access is least-privilege, personal, revocable, and may be suspended immediately for security or safety. ## 11. Reports, warnings, investigations, and voting Any community member may privately report a Partner or Crew member. Anonymous reports may be accepted when supported, although missing evidence may limit action. A report should identify the people, approximate time, app/platform, conduct, requested help, and available evidence. Staff warnings receive Moderator review; Moderator warnings receive Administrator review. An Administrator may investigate and, when immediate intervention is necessary, temporarily mute or suspend a Partner, hide disputed material, pause technical/premium access, or revoke an affected permission. Emergency action must be documented and sent to ownership within 24 hours and expires after 72 hours unless ownership continues, changes, or ends it. The Partner must be offered a reasonable description of a material allegation and normally seven days for an optional written statement. No adverse action may be based solely on declining to submit one. Knowingly malicious, retaliatory, or fabricated reports may be reviewed separately, but an unsubstantiated report is not by itself misconduct. Active, uninvolved Crew may submit blind advisory votes. Ownership makes the final ordinary decision. A conflicted reviewer must recuse. A report involving an owner routes to the other unconflicted owner or a conflict-free written proxy; the subject may not be the sole reviewer. ## 12. Appeals The Partner receives one formal appeal after a final ownership decision. It must normally be submitted within 14 days and identify the challenged result, claimed factual or process error, requested outcome, and supporting material. A different unconflicted Owner, Co-Owner, or written proxy reviews it. A case may be reopened after the appeal for significant new evidence, fraud, or serious process error. An appeal does not automatically restore access or pause a safety measure. ## 13. Evidence, privacy, and records Investigators may preserve relevant messages, screenshots, logs, recordings, audit events, and app/surface snapshots where lawful and proportionate. The default message context is the reported event plus up to ten preceding and ten following messages when available. Evidence collection excludes unrelated private conversations, unrestricted databases, credentials, secrets, and unnecessary payment information. Ticket and investigation access is limited to assigned investigators, ownership, and voters receiving only the redacted information reasonably needed. Administrative access and evidence handling are logged. Ordinary warnings remain for the life of the Partner role or accepted Terms. Major infractions, Administrator interventions, emergency actions, and owner decisions remain for the maximum lawful period and migrate to a secure archive if a system is retired. The Partner may request a redacted copy and correction of objectively false facts, subject to other people's privacy, security, privilege, and confidential deliberations. ## 14. Content, branding, and publicity Each party keeps ownership of its pre-existing names, marks, content, and other IP. The Partner confirms authority to provide submitted names, avatars, channel names, logos, clips, screenshots, testimonials, project descriptions, and other materials. The Partner grants SpaceMountain.Live a non-exclusive, worldwide, royalty-free license during participation to host, reproduce, format, display, demonstrate, distribute, and promote approved submitted materials for the relationship, events, directories, spotlights, documentation, and historical records. This license may use reasonable attribution and technical adaptations but does not transfer ownership. The Partner may revoke future promotional use by written notice. SPMT will stop new use within a reasonable operational period but may retain lawful historical credits, archived announcements, event records, backups pending rotation, and materials that cannot reasonably be recalled. Disputed material may be hidden pending review. Copyright, trademark, privacy, or other rights complaints use the legal-reporting path published by ownership. ## 15. Confidentiality Nonpublic security information, credentials, personal data, business plans, unreleased features, private reports, evidence, votes, developer materials, studio previews, and information marked or reasonably understood as confidential may be used only for the authorized purpose and disclosed only to authorized people. Confidentiality does not cover information lawfully public without breach, already known without duty, independently developed, or lawfully received from another source. Required legal disclosure should be limited and, where lawful, promptly reported so protective steps may be considered. ## 16. Payments and taxes No compensation, revenue share, referral fee, bounty, reimbursement, prize, or payment is promised. Future paid work or deals require a separate written agreement identifying duties, amount, approval, tax responsibility, and terms. When verified and available, SPMT may provide an embedded interface that routes approved payment instructions to a linked account through PayPal. PayPal, not SPMT, operates the payment rails and may impose eligibility, identity, tax, sanctions, fraud, chargeback, and account rules. Until verified live, no embedded payment capability is promised. ## 17. Suspension, ending participation, and offboarding The Partner or ownership may end participation at any time. Advance notice is requested when practical but not required for safety, security, legal, provider, or serious conduct reasons. On suspension or ending: - Partner badges, listings, premium access, private channels, keys, permissions, opportunities, and new brand use may end immediately; - the Partner must stop claiming current status and return or securely delete confidential exports, credentials, files, devices, and materials as directed; - reasonable transition cooperation may be requested but creates no unpaid-work obligation; - lawful records, accepted documents, historical credits, confidentiality, IP licenses for retained records, dispute terms, and accrued rights survive; and - reapplication is normally allowed after ownership review, but ownership may delay or permanently bar it after a serious documented incident. ## 18. Changes, electronic acceptance, and notices These Terms are accepted separately through the SPMT process defined in the Electronic Acceptance Schedule. Continued participation alone is not acceptance. Material revisions require a new version, change summary, and affirmative reacceptance. Nonmaterial corrections may be announced without reacceptance. Notices may appear in the SPMT account, authenticated ticket system, official email when provisioned, or privacy-minimized Discord DM with a secure link. The SPMT record is authoritative. ## 19. General provisions These Terms and incorporated schedules are the complete Partner community understanding unless a signed addendum applies. Invalid provisions should be narrowed or severed without rewriting the remainder. Delay in enforcement is not a waiver. Illinois law governs to the extent a different nonwaivable law does not apply, and disputes should first use the private SPMT ticket and appeal process before court proceedings when lawful and practical. No document can eliminate nonwaivable rights or decide legal classification by label. Before publication and acceptance, this file is only the Owner-approved source draft and not an active agreement with any participant. --- # SpaceMountain.Live Crew and Administrator Community Terms Status: **Owner-approved final draft - effective only after publication and acceptance** Version: `1.0` Prepared: 2026-08-02 Administrative home and governing law: Illinois, United States These Crew and Administrator Community Terms (the **Terms**) govern recognized human Staff, Moderators, and Administrators. They become effective for a participant only after owner publication, role approval, assignment of an effective date, and affirmative acceptance under the [Electronic Acceptance Schedule](ELECTRONIC_ACCEPTANCE_SCHEDULE.md). ## 1. Organization and covered ecosystem SpaceMountain.Live is an owner-operated project and creator ecosystem also known as SpaceMountain, SPMT, or spmt.live. `mtman1987` is Owner and `akhiteddy` is Co-Owner. The owner-owned and operated ecosystem includes SPMT/Creator Cloud, SpaceMountain, Shipyard, Commlink, Athena OS, StreamWeaver, Discord Stream Hub, HearMeOut and its DJ Worker, ChatTag, Quackverse while offered, Fly Machine Rotator, MountainView, SpaceMountain Companion, platform APIs, `@spmt/sdk`, and the `spmt` CLI. The retired Space Mountain dashboard is owner-owned but not an active service. AETHERRA is separately owned and operated by Co-Owner `akhiteddy` as an external partner application. Crew authority does not extend into AETHERRA's code, product data, billing, deployment, backups, or operations unless a separate written delegation says so. Future owner-operated services become covered after notice. Material new duties, payment terms, data use, IP grants, dispute terms, or authority require affirmative acceptance of a revised document or addendum. ## 2. Definitions - **Mountaineer**: a member of the wider SpaceMountain.Live community. - **Crew**: the umbrella for recognized human Staff, Moderators, and Administrators. - **Staff**: an entry-level recognized Crew member who may assist, observe, document, help community members, and issue Staff-level warnings. - **Moderator**: Crew authorized to review Staff warnings, apply published community rules within granted tools, document findings, and escalate to an Administrator. Moderator status alone does not grant suspension authority. - **Administrator**: senior Crew authorized to review Moderator matters, investigate, coordinate access and operations within granted permissions, and take the narrow temporary actions in these Terms. - **Ownership**: the Owner, Co-Owner, or a written proxy acting within a dated delegation. Ownership has final ordinary decision authority. - **Written Proxy**: a named person whose dated record states the approving owner, authority, limits, duration, and revocation terms. - **Official Account**: the named SPMT identity assigned or approved for official activity. An `@spmt.live` identity is not necessarily an email mailbox. - **Warning**: a documented concern with a level, source, facts, evidence, escalation state, and outcome, including an outcome of no further action. - **Major Infraction**: serious or potentially damaging conduct, including credible harassment, threats, fraud, exploitation, impersonation, deliberate security/privacy misconduct, or platform/reward manipulation. - **Emergency Action**: a narrow temporary protection taken before ordinary review because delay could materially harm a person, community, system, evidence, or ongoing investigation. ## 3. Appointment, eligibility, and acceptance A Crew participant must be at least 18 years old, use a named SPMT identity, provide accurate information, disclose material conflicts, complete assigned security/privacy onboarding, and accept these Terms and the current role and permission schedule. Ownership appoints, promotes, demotes, suspends, renames, and retires human roles. Administrators may recommend changes but cannot permanently change a person's role without ownership approval. A proxy may act only within its written delegation. Active status means the person currently holds the role, has not resigned or been suspended, maintains required account security, and responds or participates when personally available. No hours, shifts, quotas, mandatory availability, or minimum case count are required. ## 4. Unpaid community participation; no authority to bind Crew participation is optional and unpaid unless a separate written paid arrangement expressly applies. These Terms create no promise of employment, independent contracting, wages, salary, future work, reimbursement, agency, fiduciary status, legal partnership, joint venture, or guaranteed benefit. A Crew participant may stop participating at any time and may decline an assignment. No participant may sign a contract, hire or fire, incur an expense, promise a benefit or payment, access payment accounts, make legal statements, or bind SpaceMountain.Live unless a separate written delegation expressly grants that act. Nothing waives compensation, worker-status, or other rights that cannot lawfully be waived. If actual activities become required work or create a paid or otherwise regulated relationship, those activities must pause until ownership issues a separate written arrangement appropriate to that relationship. ## 5. Human role hierarchy and overlap The working review hierarchy is: 1. Staff documents and escalates to a Moderator. 2. Moderator reviews and escalates material matters to an Administrator. 3. Administrator investigates, coordinates, and escalates material findings to ownership. 4. Owner, Co-Owner, or an authorized written proxy makes the final ordinary decision. Partner and Administrator are mutually exclusive primary roles. A Partner may hold Staff or Moderator status only through a separate written appointment and acceptance. Any Partner or Crew participant may separately accept Developer and SDK terms. Human Crew must not be confused with AI Crew personas, which are software capabilities governed by technical permissions and have no human vote or governance authority. ## 6. Shared duties Every Crew participant agrees to: - apply published rules in good faith without favoritism, retaliation, discrimination, harassment, exploitation, or personal advantage; - use the approved ticket system or interim private reporting route; - create accurate, neutral records of warnings, interventions, evidence, decisions, and outcomes; - protect credentials, personal data, reports, deliberations, private logs, recordings, rooms, and linked-account information; - access only what is reasonably needed for an assigned purpose; - disclose conflicts and recuse when required; - escalate credible threats, self-harm emergencies, child-safety issues, payment disputes, law-enforcement requests, privacy/security incidents, and uncertain legal complaints instead of improvising; - maintain available multi-factor authentication and promptly report a compromised account or device; - avoid unauthorized changes to points, XP, game state, prizes, roles, Partner status, evidence, audit history, or application votes; - follow applicable law, Community Rules, and relevant third-party terms; and - never represent planned, experimental, degraded, or unavailable behavior as working or guaranteed. ## 7. Role authority matrix | Action | Staff | Moderator | Administrator | Ownership/proxy | | --- | --- | --- | --- | --- | | Help a member and open a ticket | Yes | Yes | Yes | Yes | | Record an observation or warning | Staff level | Moderator level | Administrator level | Yes | | Review Staff warning | View if assigned | Yes | Yes | Yes | | Review Moderator warning | No | Participate if unconflicted | Yes | Yes | | Gather proportionate evidence | If assigned | If assigned | Yes | Yes | | Submit blind advisory vote | If active/unconflicted | If active/unconflicted | If active/unconflicted | May review votes | | Mute or suspend a Partner temporarily | No | No, unless separately delegated | Emergency/temporary only | Yes | | Hide disputed material or pause affected access | No | No, unless separately delegated | Emergency/temporary only | Yes | | Permanently change role or Partner status | No | No | Recommend only | Yes | | Promise payment, contract, legal position, or refund | No | No | No | Only through approved writing | | Access payment account or unrestricted secrets | No | No | No by role alone | Only specifically authorized owner | | Make final ordinary decision | No | No | Recommend only | Yes | Permissions remain least-privilege and app-specific. A title does not grant every technical control. Where the permission system and this table differ, the narrower authority applies until ownership corrects the mismatch. ## 8. Warnings and review levels Every warning must record: - warning ID and level; - issuing person's SPMT identity and role; - subject and affected community/app; - facts stated neutrally and the applicable rule version; - evidence references and integrity information; - conflicts or recusals; - escalation and review history; - any optional written statement; - advisory votes where applicable; and - outcome, including no further action. A Staff warning triggers Moderator review. A Moderator warning triggers Administrator review. Administrator findings and most material cases proceed to ownership. A warning is not itself proof of misconduct, and escalation is not punishment. ## 9. Complaints, tickets, and investigations Any Mountaineer may privately request investigation of a Partner, Administrator, or other Crew participant. A complaint about senior Crew may go directly to the Owner, Co-Owner, or a conflict-free written proxy. Anonymous complaints may be accepted when supported, although missing information may limit action. A useful complaint identifies the people, approximate time, app/platform, conduct, requested help, and supporting material. Knowingly malicious, retaliatory, or fabricated complaints may be separately reviewed, but a report is not misconduct merely because it cannot be proven. Investigators make a good-faith determination from the available evidence. This is a community decision, not a criminal or civil court finding. Until unified SPMT tickets are live, the interim route is a private message to the Owner, Co-Owner, or designated proxy through an official SPMT/Discord account. The message should receive a ticket/reference ID and be copied into the durable private record. DMs are notification/intake paths, not the system of record. ## 10. Evidence boundaries Investigators may preserve relevant messages, screenshots, logs, recordings, audit data, and app/surface snapshots when lawful and proportionate. The default context is the reported event plus up to ten preceding and ten following messages when available. Each registered app may provide its app/version, health, route/surface, tenant-safe actor/session references, relevant configuration state, and recent correlated events. Evidence collection must not become an unrestricted copy of an entire database, unrelated private conversations, credentials, tokens, payment details, or raw logs. Secrets and unrelated personal data must be redacted. Evidence should be hashed, access-controlled, attributed, timestamped, and preserved with chain of custody. Every view, export, comment, warning, assignment, status change, escalation, decision, appeal, reopening, and closure must be auditable. ## 11. Written statements and fair process Before a warning leads to material action, affected people should receive a reasonable description of the allegation and normally seven days to submit an optional written statement. An emergency may shorten the period, but the reason must be documented and a later statement opportunity preserved. Declining a statement alone is not grounds for punitive action. A submitted statement may be retained and used in the participant's defense in the current or a future related proceeding. Only assigned investigators and ownership may view full complaints and evidence. Voters receive a redacted case summary unless more detail is reasonably necessary. Confidentiality, security, privilege, and the privacy of other people may limit disclosure. ## 12. Blind advisory voting and conflicts Active, uninvolved recognized human Crew may submit one blind advisory vote in an internal application or case review. Votes are attributed in the private audit record but visible only to ownership or the authorized decision-maker. Votes inform but do not bind the decision. A majority does not guarantee action, and a tie has no automatic effect. Ownership records the final outcome and enough reasoning to distinguish it from the advisory vote. A person with direct involvement, close personal interest, material conflict, or a credible appearance of bias must disclose it and recuse from voting, investigation, and unnecessary evidence access. A report about the Owner or Co-Owner routes to the other unconflicted owner or a conflict-free written proxy. The subject may not be the sole reviewer. ## 13. Emergency Administrator authority Only an Administrator or ownership may, before full review, temporarily mute or suspend a Partner, hide disputed material, pause affected premium/technical access, lock a ticket, or revoke an affected permission when delay could cause serious or continuing harm. Examples include credible harassment or threats directed at Mountaineers, active fraud, account compromise, evidence destruction, privacy/security exposure, or dangerous platform manipulation. Emergency action must: - be no broader than necessary; - preserve rather than alter evidence; - state the reason, scope, systems, time, and issuing Administrator; - notify ownership within 24 hours; - permit a written statement and review as soon as practical; and - expire after 72 hours unless ownership continues, changes, or ends it. Emergency action is not a final finding. Abuse of emergency authority is itself reviewable and permanently recorded. ## 14. Final decisions and appeals Final ordinary authority remains with the Owner, Co-Owner, or written proxy acting within scope. The decision record identifies findings, action, duration, conditions, appeal route, and treatment of conflicting votes. A participant receives one formal appeal after a final ownership decision. It must normally be filed within 14 days and identify the result, claimed factual or process error, requested outcome, and supporting material. A different unconflicted Owner, Co-Owner, or proxy reviews it. Significant new evidence, fraud, or serious process error may justify reopening after the appeal. An appeal does not automatically restore access or pause a safety measure. ## 15. Records, copies, correction, and retention Ordinary warning records remain for the life of the applicable role or accepted Terms. Major infractions, Administrator interventions, emergency actions, and owner decisions remain for the maximum period permitted by applicable law and migrate to a secure archive if an app or branch retires. Permanent history may be considered in a later application for the same, another, or a new role. Participants may request a redacted copy of their own record and correction of objectively false facts. SPMT may withhold other people's personal data, confidential deliberations, security details, privileged material, and information whose disclosure could create harm. Records may be shared across owner-operated SPMT branches only for legitimate role, safety, security, support, or application purposes. AETHERRA receives no automatic access because it is separately owned and operated. ## 16. Official accounts and system monitoring Official activity must use named personal accounts. Shared accounts, credential sharing, session-cookie sharing, generic authentication, and unattributed administrative acts are prohibited. SPMT retains administrative recovery control over SPMT-owned official accounts. With notice, official-system activity may be logged and monitored for security, support, compliance, evidence, and audit. This does not authorize unlimited access to unrelated personal accounts or private activity outside SPMT systems. Crew must keep secrets in approved server-side or managed stores, use minimum permissions, enable available multi-factor authentication, and promptly report compromise. No raw tokens, passwords, recovery codes, private media, payment details, or unrestricted logs may be placed in tickets, chat, or source control. ## 17. Discretionary appreciation and access benefits Crew may receive complimentary premium access across available SPMT apps, specialized shoutouts, promotional treatment, early opportunities, and first priority consideration for databases, technology, applications, and technical beta access. Crew receives second priority consideration for exclusive content and studio-partner opportunities. Active Administrators currently may receive five gifted Twitch subscriptions to their own channels in most months when ownership can afford the out-of-pocket cost. This is discretionary appreciation, not a wage, salary, fixed stipend, payment for hours, or guarantee. It may be skipped, paused, changed, or ended; does not accrue; and is not transferable, exchangeable, assignable, or cash-redeemable. Benefits may pause during investigation or suspension and normally end immediately when the qualifying role ends. Third-party availability, platform terms, tax treatment, and ownership resources apply. Future paid activity requires a separate written arrangement. ## 18. Confidentiality, privacy, and conduct Nonpublic reports, evidence, votes, statements, personal data, credentials, security information, business plans, unreleased features, studio previews, developer material, private logs, and information marked or reasonably understood as confidential may be used only for the assigned purpose. Crew must not access information out of curiosity, for gossip, retaliation, competitive advantage, or personal benefit. Confidentiality continues after the role ends. Required legal disclosure should be limited and, where lawful, promptly reported so protective steps may be considered. ## 19. Suspension, resignation, removal, and offboarding The participant or ownership may end participation at any time. Advance notice is requested when practical but is not required for safety, security, legal, provider, or serious conduct reasons. On suspension or ending: - roles, private channels, keys, sessions, premium access, votes, assignments, dashboards, app permissions, and official-system access may end immediately; - the participant must stop claiming current authority; - confidential exports, credentials, files, keys, devices, and materials must be returned or securely deleted as directed; - reasonable transition information may be requested but creates no unpaid-work obligation; - lawful records, accepted documents, confidentiality, evidence integrity, dispute terms, and accrued rights survive; and - reapplication may be delayed or permanently barred after a serious documented incident. ## 20. Changes, electronic acceptance, and notices These Terms and the current role/permission assignment are accepted through the Electronic Acceptance Schedule. Continued participation alone is not acceptance. Material changes require a version, change summary, and affirmative reacceptance. Nonmaterial corrections may be announced without reacceptance. Notices may appear in the SPMT account, authenticated ticket system, official email when provisioned, or a privacy-minimized Discord DM containing a secure link. The durable SPMT record is authoritative. ## 21. General provisions These Terms and incorporated schedules are the complete Crew community understanding unless a signed role assignment, delegation, paid arrangement, or other addendum applies. Invalid provisions should be narrowed or severed without rewriting the remainder. Delay in enforcement is not a waiver. Illinois law governs to the extent a different nonwaivable law does not apply. Disputes should first use the private SPMT ticket and appeal process before court proceedings when lawful and practical. No document can eliminate nonwaivable rights or decide legal classification by label. Before publication and acceptance, this file is only the Owner-approved source draft and not an active agreement with any participant. --- # SpaceMountain.Live Developer and SDK Community Terms Status: **Owner-approved final draft - effective only after publication and acceptance** Version: `1.0` Prepared: 2026-08-02 Administrative home and governing law: Illinois, United States These Developer and SDK Community Terms (the **Terms**) govern approval-only access to SPMT developer services, APIs, `@spmt/sdk`, the `spmt` CLI, app review, hosting, events, webhooks, and ecosystem integration. They become effective for a Developer only after owner approval, publication, assignment of an effective date, and affirmative acceptance under the [Electronic Acceptance Schedule](ELECTRONIC_ACCEPTANCE_SCHEDULE.md). ## 1. Parties and relationship **SpaceMountain.Live** is the owner-operated project and ecosystem also known as SpaceMountain, SPMT, or spmt.live. `mtman1987` is Owner and `akhiteddy` is Co-Owner. **Developer** means the individual SPMT account holder approved to build, operate, contribute to, or integrate an application, plugin, bot, workflow, service, or other project. A Developer may also be a Partner, Staff, Moderator, or Administrator under separately accepted terms. Developer participation is optional, non-exclusive, and unpaid unless a separate written commercial or paid-work agreement applies. These Terms create no employment, agency, legal partnership, joint venture, franchise, fiduciary relationship, guaranteed support, or authority to bind SPMT. Nothing waives compensation, worker-status, IP, privacy, or other rights that cannot lawfully be waived. Required paid work must use a separate written arrangement. ## 2. Ecosystem and ownership map The owner-owned and operated first-party ecosystem includes SPMT/Creator Cloud, SpaceMountain, Shipyard, Commlink, Athena OS, StreamWeaver, Discord Stream Hub, HearMeOut and its DJ Worker, ChatTag, Quackverse while offered, Fly Machine Rotator, MountainView, SpaceMountain Companion, platform APIs, `@spmt/sdk`, and the `spmt` CLI. The retired Space Mountain dashboard is owner-owned but not an active service. AETHERRA is separately owned and operated by Co-Owner `akhiteddy` as an external partner application. Unless a signed addendum reallocates a specific responsibility, AETHERRA owns and controls its code, product data, feature state, billing, deployment, backups, operations, and product support. SPMT owns its identity/platform contracts and only receives authorized integration data. The same boundary applies to another external Developer application: the Developer owns the application and its app-specific data and operations; SPMT owns SPMT identity, shared permissions, app registry/install state, Commlink platform records, shared events, shared XP, and SPMT platform services. ## 3. Definitions - **Developer Services**: SPMT APIs, OAuth/session paths, SDK, CLI, app registry, Shipyard review/listing, events, webhooks, Commlink, test tools, documentation, and approved credentials. - **Developer Project**: code, assets, configuration, documentation, data, or a service supplied or operated by the Developer. - **Hosted Project**: a Developer Project or approved copy that SPMT stores, builds, deploys, operates, tests, displays, demonstrates, maintains, or backs up. - **External App**: a Developer-operated application whose product runtime and app-specific data remain outside SPMT ownership. - **Platform Key**: a server-only, scoped, revocable, app-bound SPMT credential. - **Manifest**: the public `spmt.app.json` app description, owner, version, launch/auth/health URLs, status, and requested scopes. - **Event**: a bounded, versioned ecosystem record with stable identifiers, timestamps, source app, actor/tenant context, and a safe payload. - **Community Rules**: the current acceptable-use, privacy, security, content, app-review, and platform rules incorporated by versioned acceptance. ## 4. Approval-only access and app review Developer Services remain approval-only unless ownership later publishes a different program. Access may require an application, accurate Manifest, technical review, owner approval, separate credentials for each app/environment, testing, and ongoing compliance. The standard production-shaped path currently expects Node.js 18 or newer for the JavaScript package, `@spmt/sdk`, the `spmt` CLI, a public `spmt.app.json`, a server-side `SPMT_API_KEY`, doctor/submit checks, and an app-bound key. Non-Node clients may use an approved HTTP client while preserving the same security and contract rules. An accepted application does not guarantee public listing, certification, promotion, continued API access, support, or production approval. Ownership may label an integration development, experimental, degraded, unavailable, approved, suspended, or retired according to current evidence. ## 5. Limited SDK and documentation license The SDK repository metadata currently says `UNLICENSED`. It must not be described as open source or generally licensed to the public. While these Terms remain active, SPMT grants the approved Developer a limited, personal, non-exclusive, non-transferable, revocable license to download, use, execute, and make the minimum internal modifications to approved SDK samples and tooling needed to build and operate the approved integration. This license does not permit the Developer to: - resell, sublicense, publish, mirror, or redistribute the SDK as a competing package; - remove ownership, attribution, security, or license notices; - offer SPMT credentials or platform access to another person; - claim that the SDK is open source; - reverse engineer or circumvent authentication, authorization, rate limits, tenant boundaries, audit, or security controls; or - use SPMT names or marks beyond approved integration identification. Interoperability work and security research must stay within applicable law and the private vulnerability-reporting process. A later published SDK license may replace this section only after notice and affirmative acceptance when the change is material. ## 6. Identity and account requirements An ecosystem app must use SPMT as the shared identity source rather than creating a competing global identity. The app may keep a separate product account where necessary, but linking must use immutable provider/account IDs and explicit authorization; display names are never ownership proof. OAuth authenticates and authorizes access but is not acceptance of these Terms. Browser and game clients must not contain a Platform Key. Privileged operations run through a trusted backend with a scoped server credential. Official and developer activity must use named accounts. Shared accounts, credential sharing, session-cookie sharing, generic authentication, and unattributed administrative changes are prohibited. SPMT may monitor official Developer Services after notice for security, support, compliance, metering, and audit. ## 7. Minimum permissions and credentials The Developer must: - request only the scopes needed for the approved feature; - keep Platform Keys, OAuth secrets, webhook secrets, tokens, recovery codes, private logs, and payment details server-side or in an approved secret store; - never commit or transmit secrets through source control, events, tickets, chat, client bundles, screenshots, or public logs; - use separate app-bound credentials for each approved app and environment; - rotate and revoke credentials promptly after compromise, personnel change, suspension, or termination; - reject missing tenant, actor, app, destination, or authorization context when the operation requires it; and - honor disconnect and grant revocation without corrupting the Developer's independent product account or app-specific data. SPMT may immediately suspend a key, scope, webhook, listing, or Developer Service for suspected abuse, compromise, cross-tenant access, excessive load, legal risk, or provider requirements while the matter is reviewed. ## 8. Manifest, health, and truthful status The Developer must keep accurate: - stable app ID, name, description, owner, and support route; - launch, OAuth callback, top-level, health, and version URLs; - current version and status; - requested permissions and user explanation; - data, billing, external-provider, and app-ownership boundaries; and - material limitations, outages, migration state, and retirement notices. The app must support a top-level launch and not assume iframe embedding always works. Health/version metadata must be truthful. A successful build, existing page, `200` response, or container does not prove that every feature works. ## 9. Events, webhooks, and cross-app behavior Events and webhook messages must use stable immutable IDs, timestamps, source-app identity, tenant/actor context, bounded payloads, and idempotency keys. Retries must not duplicate a payment, reward, XP award, moderation act, message, workflow, or other side effect. The Developer must not place passwords, tokens, recovery codes, raw private records, unnecessary personal data, payment details, unrestricted logs, or private media into events. Webhook consumers must verify authenticity and handle duplicate delivery, retry, timeout, out-of-order arrival, malformed payloads, revocation, and unavailable dependencies. No app may manipulate points, XP, game state, rewards, rankings, installs, votes, tickets, or acceptance records, or replay events to receive duplicate benefits. ## 10. Data ownership and privacy SPMT owns and controls SPMT identity/session records, linked-account references, app registry and install state, shared permissions, SPMT Commlink platform records, ecosystem-event records, shared XP, and Athena context summaries, subject to applicable user and privacy rights. The Developer owns and controls the Developer Project, app-specific settings, feature state, game state, rooms, automation, app database, billing, deployment, backups, and app support unless a signed addendum says otherwise. The Developer is responsible for a clear privacy notice, lawful collection and use, consent/authorization, data minimization, security, retention/deletion, user requests, subprocessors, and incident response for Developer-controlled data. The Developer must not imply that SPMT is responsible for independently collected product data. A separate data-processing agreement is required when the actual relationship needs one. Each side may use integration data only for the documented purpose and must support lawful access, correction, export, deletion, disconnect, and revocation rights. Neither side may silently use the other's data to train an unrelated model, sell profiles, or create an undisclosed competing identity graph. ## 11. Security and incident reporting The Developer must use reasonable safeguards appropriate to the data and risk, including access control, encryption in transit, safe secret storage, dependency review, backups, restore/rollback capability, logging without raw secrets, and least privilege. The Developer must privately report a suspected critical vulnerability, credential exposure, cross-tenant access, unauthorized acceptance, material personal-data incident, or active exploitation as soon as practical and within 24 hours of discovery. Public disclosure must wait for coordinated remediation or a lawful disclosure requirement. The Developer must cooperate reasonably in containment, evidence preservation, credential rotation, user/provider notice, remediation, and a truthful post-incident record. SPMT may require a focused security review before access is restored. ## 12. Testing, deployment, and changes Before a production claim, the integration must pass applicable contract, authorization, tenant-isolation, app-binding, event/webhook, migration, rollback, restart/restore, failure, and smoke tests. Shared-contract work follows owner first: freeze and verify the SPMT contract, migrate one consumer, observe telemetry, preserve compatibility where approved, and remove the old path only after evidence and rollback readiness. The Developer must not deploy a material breaking change without notice, testing, rollback, and updated documentation. SPMT may require correction, degradation labels, delisting, or suspension when a release is unsafe or misrepresents capability. ## 13. API use, limits, and prohibited conduct The Developer must follow published rate, payload, retention, automation, webhook, and concurrency limits. If no numeric limit is published, use reasonable bounded traffic, caching, exponential backoff, and a request pattern that does not impair other users. The Developer may not: - scrape private or access-controlled data; - bypass scopes, tenant boundaries, rate limits, app review, payment controls, moderation, audit, or acceptance systems; - probe another tenant or user's data without written authorization; - distribute malware or deliberately vulnerable code; - use hidden fallbacks, default credentials, fabricated success states, or misleading health/status output; - impersonate SPMT, another app, user, Partner, or Crew participant; - send spam, harassment, unlawful content, deceptive promotions, or fraudulent payments; - overload, disrupt, resell, or provide unauthorized access to Developer Services; or - use SPMT data or services contrary to law, provider terms, or Community Rules. Good-faith private security reporting is not prohibited. Testing that could affect production, another user, or data requires prior written authorization. ## 14. Developer ownership and SPMT hosting license The Developer retains ownership of the Developer Project and pre-existing IP. No transfer to SPMT occurs unless a separate signed assignment expressly says so. For an approved Hosted Project, the Developer grants SPMT a worldwide, non-exclusive, royalty-free license during the hosting term to receive, copy, store, back up, build, test, scan, format, adapt for compatibility/security/ deployment/accessibility, deploy, operate, display, demonstrate, maintain, and support the approved Hosted Project solely for the ecosystem and agreed promotion. SPMT may use hosting, build, security, monitoring, backup, contractor, and infrastructure providers that are subject to appropriate access and confidentiality restrictions. Operational changes by SPMT do not transfer the Developer's underlying ownership. A change authored solely by an SPMT contributor remains owned by its author unless assigned, but the Developer receives a non-exclusive, royalty-free license to use that change with the Hosted Project; SPMT receives the corresponding license needed to continue operating it. Material feature or ownership changes should use a separate contribution or statement-of-work record. The Developer may revoke ordinary hosting permission on 30 days' written notice. SPMT may use the notice period for export and orderly shutdown. Immediate removal may be required for rights violations, security, provider demand, or law. Disaster-recovery and security backups may remain for up to 30 days after removal, inaccessible to ordinary use and then deleted or overwritten through normal rotation, subject to lawful holds and required records. ## 15. Commercial applications and payments Commercial applications and independent monetization of Developer-owned work are allowed subject to app review, accurate disclosure, applicable law, provider/payment rules, and a separate commercial addendum for any SPMT fee, revenue share, referral, sponsorship, paid development, marketplace sale, or payment-processing responsibility. The Developer remains responsible for the Developer Project's prices, taxes, refunds, chargebacks, fraud, customer support, and billing unless an addendum says otherwise. When verified and available, SPMT may expose an embedded interface that routes approved payment instructions to a linked account through PayPal. PayPal, not SPMT, operates the payment rails and may impose eligibility, identity, tax, sanctions, fraud, and account rules. No embedded payment capability is promised until verified live. ## 16. Third-party code and services The Developer must identify material third-party code, data, models, assets, APIs, dependencies, and licenses and comply with their terms. The Developer must not submit content or code without the rights needed for hosting, operation, distribution, display, and promotion. Twitch, Discord, YouTube/media providers, LiveKit, PayPal, Fly.io, GitHub, OBS/local companion software, AI/model providers, package registries, hosting providers, and other services operate independently. Their outages, policy changes, rate limits, bans, content actions, or discontinued APIs may disable an integration. SPMT may substitute or discontinue a dependency and does not guarantee third-party availability. ## 17. Branding and promotion Each party keeps ownership of its names, marks, branding, content, and pre-existing materials. The Developer confirms authority to submit every project name, logo, avatar, screenshot, demo, description, testimonial, clip, and other promotional asset. The Developer grants SPMT a non-exclusive, worldwide, royalty-free license during participation to host, reproduce, format, display, demonstrate, distribute, and promote approved project names, descriptions, screenshots, demos, branding, attribution, and related materials for Shipyard, documentation, events, directories, announcements, and ecosystem promotion. The Developer may revoke future promotional use by written notice. SPMT will stop new use within a reasonable operational period but may retain lawful historical credits, archived announcements, event records, documentation of prior versions, backups pending rotation, and materials that cannot reasonably be recalled. Disputed material may be hidden pending review. The Developer receives a narrow, revocable license to use approved SPMT names and marks only to truthfully identify the active integration. No confusing domains, altered marks, unauthorized merchandise, endorsement claims, or authority to speak for SPMT are granted. ## 18. Availability, support, and changes Developer Services are provided on an as-available, evolving basis. No uptime, response time, support level, compatibility, data preservation, continued API, continued SDK version, listing, certification, or future feature is guaranteed unless a signed service-level or commercial addendum says otherwise. SPMT will use reasonable efforts to announce a material breaking change or retirement through the developer documentation and account notice. Security, legal, provider, abuse, and urgent reliability changes may occur immediately. The Developer must design for retries, degradation, revocation, export, and orderly shutdown. ## 19. Abandoned projects A project may be treated as abandoned when its owner is unreachable, required credentials or dependencies remain broken, security issues are unaddressed, or the project has no functioning support/maintenance path after reasonable notice. SPMT may mark it degraded, disable installs, revoke credentials, delist it, preserve an evidence/archive copy, provide a reasonable export opportunity, and shut down owner-operated hosting. SPMT does not acquire ownership merely because a project is abandoned. ## 20. Confidentiality Nonpublic credentials, source, vulnerabilities, personal data, business plans, private reports, security information, unreleased features, test data, logs, and information marked or reasonably understood as confidential may be used only for the approved purpose and shared only with authorized people. Confidentiality does not cover information lawfully public without breach, already known without duty, independently developed, or lawfully received from another source. Required legal disclosure should be limited and, where lawful, promptly reported so protective steps may be considered. ## 21. Suspension, termination, and offboarding The Developer or ownership may end participation at any time. Thirty days' notice is requested for ordinary hosted-project removal; advance notice is not required for security, abuse, legal, rights, provider, or serious reliability reasons. On suspension or termination: - keys, scopes, sessions, webhooks, listings, certification, premium access, private channels, and SPMT brand permission may end immediately; - the Developer must stop claiming active status and return or securely delete SPMT confidential material and credentials; - SPMT will provide a reasonable export opportunity where safe and applicable; - disconnect must not delete or corrupt the Developer's independent account or app data; - lawful records, accepted documents, confidentiality, data duties, incident obligations, retained-backup limits, historical credits, and accrued rights survive; and - reapplication may be delayed or permanently barred after serious documented abuse. ## 22. Changes, electronic acceptance, and notices These Terms are accepted separately through the Electronic Acceptance Schedule. Continued use alone is not acceptance. Material changes to SDK rights, data use, security, payment, IP, liability, disputes, or termination require a new version, change summary, and affirmative reacceptance. Notices may appear in the SPMT developer account, authenticated ticket system, documentation, official email when provisioned, or privacy-minimized Discord DM containing a secure link. The durable SPMT record is authoritative. ## 23. General provisions These Terms and incorporated schedules are the complete Developer community understanding unless a signed Manifest approval, contribution record, data agreement, service level, statement of work, or commercial addendum applies. Invalid provisions should be narrowed or severed without rewriting the remainder. Delay in enforcement is not a waiver. Illinois law governs to the extent a different nonwaivable law does not apply. Disputes should first use the private SPMT ticket and appeal process before court proceedings when lawful and practical. No document can eliminate nonwaivable rights or decide legal classification by label. Before publication and acceptance, this file is only the Owner-approved source draft and not an active agreement with any Developer. --- # Shared Electronic Acceptance Schedule Status: **Owner-approved final draft - effective with the adopted role terms** Schedule version: `1.0` Prepared: 2026-08-02 This schedule applies to the Partner, Crew and Administrator, and Developer and SDK Community Terms. It defines the acceptance evidence the SPMT system must create before any role document is treated as accepted. ## 1. Separate acceptance by role Each role document is accepted separately. A multi-role participant receives a separate acceptance record for every applicable document. - Partner accepts the Partner Community Terms. - Staff, Moderator, and Administrator accept the Crew and Administrator Community Terms and their current role/permission assignment. - Developer or SDK user accepts the Developer and SDK Community Terms. Partner and Administrator may not be simultaneous primary roles. Partner plus Staff or Moderator requires a separate written Crew appointment. Any Partner, Crew member, or Administrator may separately participate as a Developer. ## 2. Application and review record Before presenting terms, SPMT should preserve: - applicant's stable SPMT account ID and current display handle; - requested role and, for a Partner liaison, the represented outside community; - submitted answers and attachments; - submission time and time in each application state; - eligible reviewers, each blind advisory vote and timestamp, abstentions, and recusals; - decision-maker, decision, reason, and time; - acknowledgment, approval, or denial notices and delivery result; and - the exact role document offered after approval. The applicant should receive a private acknowledgment with the current rules, responsibilities, discretionary benefits, review process, privacy notice, and expected next step. Approval and denial notices remain private. Approval does not activate the role until every required document is accepted. ## 3. Presentation requirements The acceptance page must: 1. Require a current authenticated SPMT session. 2. Display the participant's account and proposed role. 3. Display the complete document or a readable embedded copy. 4. Provide stable links to download and print the exact offered document. 5. Show the document title, version, effective date, and SHA-256 hash. 6. Link the applicable privacy notice, community rules, security requirements, and any incorporated schedule. 7. Explain that the transaction is electronic and offer a reasonable alternative acceptance method for accessibility needs. 8. Provide a way to cancel, report the wrong account/role, or correct an input before acceptance. 9. Require an unchecked acknowledgment confirming that the participant has reviewed the document and intends to accept it electronically. 10. Require the affirmative button **Accept Community Terms**. SPMT OAuth authenticates the account but is not acceptance by itself. Silence, prechecked boxes, a login, use of another app, or continued participation alone does not replace the affirmative acceptance action. ## 4. Server-side acceptance record On acceptance, the server creates a unique, append-only acceptance ID and stores at least: - stable SPMT account ID; - current display handle and immutable linked-provider IDs used for authentication, when relevant and lawfully retained; - accepted role and any role-assignment version; - document title, version, effective date, canonical URL, and SHA-256 hash; - incorporated schedule/policy versions and hashes; - exact acceptance-button label; - UTC presentation and acceptance timestamps; - authentication method, session ID or non-secret session fingerprint, and recent-authentication state; - application/approval record ID, if applicable; - client/user-agent and network attribution only to the extent disclosed by the published privacy notice; - consent to electronic records and acknowledgment state; - delivery method and result for the accepted copy; and - superseding, revocation, correction, or termination references added later. Never store an OAuth token, password, recovery code, API key, session cookie, or other reusable secret in the acceptance record. ## 5. Receipt and participant access Immediately after acceptance, SPMT should: - show a success page with the acceptance ID, role, version, timestamp, and hash; - provide a downloadable accepted copy and receipt; - retain the same copy in the participant's account dashboard; - send a privacy-minimized notification or DM containing a secure link when that route is available; and - provide the correction/support route if the wrong account, role, or document was accepted. The durable SPMT record is the system of record. A Discord DM, email, or other notification is a delivery aid and not the authoritative copy. ## 6. Versioning and reacceptance - Nonmaterial formatting, typo, link, or contact corrections may be announced without reacceptance when they do not alter meaning. - A material change to duties, authority, discipline, evidence use, retention, benefits, payment, data use, IP rights, SDK rights, liability, dispute terms, or termination requires a new version and affirmative reacceptance. - SPMT must show a readable change summary before reacceptance. - The former version remains available in the participant's acceptance history. - A role may be paused if required reacceptance is not completed by the stated deadline, but access needed to review, download, correct, appeal, or retrieve prior records must remain reasonably available. ## 7. Integrity and retention - Store the exact accepted bytes in a versioned, access-controlled archive. - Hash the document before presentation and verify the same hash at acceptance and receipt generation. - Log creation, viewing, download, correction, supersession, and administrative access with named SPMT identities. - Back up the authoritative copy and test restoration. - Retain the accepted document and evidence for the maximum period permitted by applicable law and the published retention schedule. - A system migration must preserve record content, attribution, timestamps, hashes, version relationships, and participant access. ## 8. Error, dispute, and correction path The participant may promptly report an automated error, wrong identity, wrong role, inaccessible record, or suspected unauthorized acceptance. SPMT must freeze activation when appropriate, preserve the evidence, investigate the attribution, record any correction, and never silently overwrite the original record. A corrected acceptance receives a new record linked to the superseded one. ## 9. Activation tests Before launch, verify: - wrong-account and expired-session rejection; - separate multi-role acceptance; - no acceptance from login alone; - exact offered/accepted/downloaded hash parity; - keyboard, screen-reader, mobile, print, and download access; - cancel and correction behavior; - retry and duplicate-click idempotency; - immutable audit and role activation only after success; - nonmaterial notice versus material reacceptance; - prior-version retrieval; - owner/admin inability to forge participant acceptance; - secret redaction; and - backup and isolated restore of acceptance records. --- ## Docs UI # Docs Page Spec ## Purpose The Docs page should make SpaceMountain understandable without leaving the app and should expose the same public documentation in a portable raw format. ## Requirements - Sidebar navigation from `docs/docs-nav.json` - Markdown rendering - Search/filter - Mermaid diagram support - Code block styling - Copy code button - Breadcrumbs - Mobile-friendly layout - A complete raw Markdown bundle generated from `docs/docs-nav.json` - A visible **Download All (.md)** action that saves the generated bundle as `SPMT-DOCS.md` - Bundle generation must fail on missing, unsafe, archived, or path-traversing manifest entries instead of silently omitting documents - The generated bundle is an output only; source Markdown files remain authoritative ## Nice To Have - Version selector - Last updated metadata - Feedback button - Related docs links - Live API examples --- ## Specifications # Platform Specification Index The `/spec` folder defines the official platform contracts. Read these before making platform-level changes: - `spec/IDENTITY_SPEC.md` - `spec/EVENT_SPEC.md` - `spec/APP_SPEC.md` - `spec/SHIPYARD_SPEC.md` - `spec/COMMLINK_SPEC.md` - `spec/ATHENA_SPEC.md` - `spec/PERMISSIONS_SPEC.md` - `spec/API_CONTRACT.md` - `spec/DESIGN_SYSTEM.md` - `spec/MARKETPLACE_SPEC.md` - `spec/AI_CREW_SPEC.md` - `spec/UI_COMPONENT_SPEC.md` Documentation explains the platform. Specifications govern the platform. --- # Identity Specification ## Principle Every user has one primary SPMT identity. Apps may keep app-specific preferences or state, but they must not become the source of truth for creator identity. ## Required User Model ```ts type SpmtUser = { id: string; username: string; handle: string; email?: string; displayName: string; avatarUrl?: string; linkedAccounts: LinkedAccount[]; createdAt: string; }; ``` ## Linked Account Model ```ts type LinkedAccount = { provider: "twitch" | "discord" | "youtube" | "kick" | "github" | "google" | "steam" | string; providerUserId: string; username?: string; displayName?: string; connectedAt: string; }; ``` ## Rules - Apps must request the current user from SPMT. - Apps must not create fake standalone identities when SPMT identity is required. - App-local profiles must reference an SPMT user ID. - Linked accounts should be matched through SPMT. - User-facing profile changes should eventually sync through SPMT. - Identity checks must be server-side for privileged actions. ## Required App Behavior When an app launches: 1. Check for a valid SPMT session or app token. 2. Request current user. 3. Load app-specific state by SPMT user ID. 4. If identity is missing, redirect to SPMT or show a clear connect action. --- # Event Specification ## Principle Apps publish events instead of directly coupling to each other. The Event Bus lets SPMT route events to Commlink, Athena, notifications, analytics, webhooks, plugins, and future apps. ## Required Event Shape ```ts type EcosystemEvent = { id: string; type: string; version: number; timestamp: string; sourceApp: string; actor?: { userId?: string; username?: string; displayName?: string; }; visibility: "private" | "creator" | "community" | "public" | "system"; payload: Record; links?: EventLink[]; }; ``` ## Event Link Shape ```ts type EventLink = { label: string; url: string; kind: "launch" | "details" | "manage" | "external"; }; ``` ## Naming Convention Use dotted names: - `stream.started` - `stream.ended` - `reward.earned` - `voice.room.created` - `discord.shoutout.created` - `automation.completed` - `plugin.installed` - `athena.command.executed` ## Rules - Events must include `type`, `sourceApp`, `timestamp`, and `payload`. - Events should include stable IDs when possible. - Do not include secrets or raw tokens. - Prefer summaries and stable references over noisy raw logs. - User-facing events may create Commlink notifications. - Useful operational events may write Athena context. --- # App Specification ## Principle An ecosystem app is a specialized module connected through SPMT. ## Required App Metadata ```ts type EcosystemApp = { id: string; name: string; description: string; category: string; launchUrl: string; authUrl?: string; healthUrl?: string; iconUrl?: string; version: string; latestVersion?: string; status: "connected" | "available" | "adapter-needed" | "planned" | "disabled" | "broken"; official: boolean; permissions: string[]; }; ``` ## Required App Capabilities Each app should support: - SPMT identity - launch URL - health/version metadata - event publishing - Commlink notifications for important events - Athena context where useful - install/enable/disable state through Shipyard ## Rules - Apps own app-specific features. - Apps do not own global identity. - Apps do not own global notifications. - Apps do not own the global app registry. - Apps should not assume they are always iframe-embedded. - Apps should support top-level launch. --- # Shipyard Specification ## Principle Shipyard manages app lifecycle and discovery. ## Lifecycle ```mermaid flowchart LR Discover --> Install --> Configure --> Enable --> Launch --> Update --> Disable --> Uninstall ``` ## App States - `available` - `installed` - `enabled` - `disabled` - `needs_update` - `broken` - `planned` - `beta` - `experimental` ## Required Card Fields Every Shipyard app card should be able to show: - name - description - category - status - version - update available - permissions - launch action - install/enable/disable action - health state ## Rules - SpaceMountain.live renders the Shipyard UI. - SPMT owns app metadata and install state. - Apps expose launch targets and version/health data. - First-party apps may have special protections from disabling if required. --- # Commlink Specification ## Principle Commlink is the unified communication layer. ## Item Types - direct message - group conversation - app message - bot message - system notice - forum activity - voice message metadata - AI conversation - notification ## Conversation Shape ```ts type Conversation = { id: string; type: "direct" | "group" | "app" | "bot" | "system" | "forum" | "ai" | "voice"; title?: string; participants: string[]; unreadCount: number; updatedAt: string; }; ``` ## Message Shape ```ts type CommlinkMessage = { id: string; conversationId: string; fromUserId?: string; sourceApp?: string; type: string; subject?: string; body: string; attachments?: unknown[]; mentions?: unknown[]; createdAt: string; readAt?: string; }; ``` ## Rules - Important app events should create Commlink-visible messages or notifications. - Commlink should filter by type. - Commlink should support unread state. - Commlink should support app and bot messages without pretending they are human DMs. - Noisy internal logs do not belong in Commlink. --- # Athena Specification ## Principle Athena is the operating intelligence of the Creator Cloud. Athena should not be a disconnected chatbot. She should understand the creator's ecosystem. ## Athena Context Athena may use: - current user - installed apps - permissions - recent events - unread messages - active rooms - game state summaries - app health - notifications - automation history - community status - memory - user goals ## Memory Shape ```ts type AthenaMemory = { id: string; userId: string; scope: "user" | "app" | "command" | "community" | "system"; topic: string; content: string; sourceApp?: string; createdAt: string; updatedAt: string; }; ``` ## Command Routing Athena may route commands to: - Shipyard - Commlink - StreamWeaver - HearMeOut - ChatTag - Discord Stream Hub - MountainView - platform plugins - other AI crew members ## Rules - Athena should receive summaries, not raw noisy logs. - Athena should respect app permissions. - Athena should identify source apps clearly. - Athena should explain what she knows and where it came from. - Athena should route specialized work to specialized apps or AI crew. --- # Permissions Specification ## Principle Permissions define what apps, plugins, API keys, and AI crew members may do. ## Permission Format Use colon-separated scopes: - `identity:read` - `apps:read` - `apps:write` - `messages:read` - `messages:write` - `events:write` - `athena:read` - `athena:write` - `webhooks:write` - `plugins:install` ## Rules - Apps request minimum necessary permissions. - Users should eventually be able to review permissions. - API keys must be scoped. - Plugin actions must be scoped. - AI crew actions must be scoped. - Privileged actions must be checked server-side. --- # API Contract ## Principle All APIs should feel consistent. ## Success Shape ```json { "success": true, "data": {}, "meta": {} } ``` ## Error Shape ```json { "success": false, "error": { "code": "not_authenticated", "message": "Not authenticated" } } ``` ## Rules - Use predictable response shapes. - Use stable error codes. - Include pagination metadata where needed. - Do not leak internal stack traces. - Keep snake_case and camelCase compatibility only where migration requires it. - Document every public endpoint. --- # Design System Specification ## Principle Every SpaceMountain app should feel like part of the same universe. ## Shared UI Concepts - dark cosmic background - glass panels - orange solar accent - blue secondary accent - rounded cards - status badges - dockable panels - command buttons - clear empty states - consistent loading states ## Component Targets Future package: `@spmt/ui` Components: - ShipyardCard - CommlinkMessage - AthenaPanel - DockWidget - NotificationCard - CreatorCard - ForumPost - StatusBadge - CommandButton - PermissionList - AppHealthBadge ## Rules - Apps may keep their own personality, but shared platform surfaces should remain visually consistent. - Status colors and labels should be centralized. - Empty states should explain the next action. - Mobile layouts should preserve core actions. --- # Marketplace Specification ## Principle Shipyard should eventually manage more than apps. Installable ecosystem items may include: - apps - plugins - themes - widgets - automation packs - Athena skills - community packs - extensions ## Required Marketplace Metadata ```ts type MarketplaceItem = { id: string; type: "app" | "plugin" | "theme" | "widget" | "automation" | "athena_skill" | "community_pack" | "extension"; name: string; author: string; description: string; version: string; permissions: string[]; screenshots?: string[]; rating?: number; downloads?: number; compatibility?: string[]; }; ``` ## Rules - Marketplace items must declare permissions. - Official items should be clearly labeled. - Beta and experimental items should be clearly labeled. - Installation should be reversible where practical. --- # AI Crew Specification ## Principle Athena can coordinate with other AI crew members. Athena is the command intelligence. Other AI may specialize. ## AI Crew Shape ```ts type AiCrewMember = { id: string; name: string; role: string; personality: string; capabilities: string[]; permissions: string[]; visibility: "private" | "crew" | "public"; memoryScopes: string[]; }; ``` ## Example Crew Roles - Athena: operating intelligence and command routing - Scarlett: community and social strategy - Moonbeam: voice, rooms, music, and emotional tone - Forge: automation and developer workflows - Atlas: app awareness and ecosystem mapping ## Rules - Athena routes work to crew when specialization helps. - Crew members must respect permissions. - Crew responses should identify source context. - Crew should not invent access to apps or data. - Memory ownership must be explicit. --- # UI Component Specification ## Principle Shared UI components help every app feel native to SpaceMountain. ## Core Components ### ShipyardCard Shows app metadata, status, version, permissions, and action buttons. ### CommlinkMessage Shows sender, source app, type, body, timestamp, attachments, and read state. ### AthenaPanel Shows current command context, suggestions, memory snippets, and routed actions. ### NotificationCard Shows title, body, source app, timestamp, action URL, and read state. ### StatusBadge Normalizes states such as online, live, disabled, broken, beta, needs update. ## Rules - Components should accept platform data models. - Components should not hard-code one app's assumptions. - Components should be accessible and responsive. - Components should work in SpaceMountain.live and future apps.