You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This milestone's own description names a broader goal than backend/infra readiness alone: getting AMS to a state where it's "fully usable by anyone through our website (expanding our existing dashboard/app, potentially building a mobile app and/or desktop app, CLI version, etc)." Every other issue in this milestone addresses the server-side plumbing (storage, auth, fleet ops, secrets, health) a hosted AMS needs — none of them decide which CLIENT surfaces a hosted AMS should actually ship, or in what order. Without an explicit decision here, apps/gittensory-miner-ui's own future direction (already being rebuilt for self-host in Wave 4 — see #5176, #5192-#5194) risks being designed twice: once for self-host, once again for hosted, instead of one client shape that serves both.
Area
AMS / Cloud architecture
Proposal
Decide and document which client surfaces a hosted AMS ships, and in what sequence, applying the same "reuse the self-host layer, don't fork it" pattern recommended for the backend: evaluate whether apps/gittensory-miner-ui (already being hardened for self-host in Wave 4) can become the SAME web dashboard for hosted customers with a hosted-mode config flag (mirroring how ORB's own dashboard already serves both self-host operators and gittensory's own hosted install from one codebase), versus where a genuinely separate mobile app, desktop app, or deeper CLI investment would need net-new work with no self-host equivalent to reuse. Explicitly sequence: what ships for a hosted AMS launch versus what's a later expansion.
Deliverables
A written decision on which client surfaces ship at hosted-AMS launch (web dashboard, at minimum) versus which are explicitly deferred (mobile app, desktop app), with reasoning.
For whichever surfaces are approved, a stated reuse plan against the existing self-host client code (apps/gittensory-miner-ui, apps/gittensory-miner-extension) rather than a from-scratch build, or an explicit, justified exception if reuse genuinely isn't viable for a specific surface.
An explicit non-decision is also an acceptable outcome for mobile/desktop specifically (e.g. "defer until after hosted AMS launch and initial customer feedback") as long as it's written down, not left ambiguous.
Resources
apps/gittensory-miner-ui (the existing self-host dashboard, already scoped for a Wave 4 rebuild)
apps/gittensory-miner-extension (the existing self-host browser extension)
The milestone's own description (client-surface goals stated by the maintainer)
This issue is a planning/decision issue only — it must not itself start building a mobile or desktop app. Any client-surface work that follows from this decision gets its own separate issue(s), scoped after this one closes. Depends on nothing else in this milestone to START (it can run in parallel with the backend-focused issues), but the control-plane architecture spec in this same milestone should ideally land first so this issue's "reuse plan" can reference an agreed backend shape rather than guessing at one.
Problem
This milestone's own description names a broader goal than backend/infra readiness alone: getting AMS to a state where it's "fully usable by anyone through our website (expanding our existing dashboard/app, potentially building a mobile app and/or desktop app, CLI version, etc)." Every other issue in this milestone addresses the server-side plumbing (storage, auth, fleet ops, secrets, health) a hosted AMS needs — none of them decide which CLIENT surfaces a hosted AMS should actually ship, or in what order. Without an explicit decision here, apps/gittensory-miner-ui's own future direction (already being rebuilt for self-host in Wave 4 — see #5176, #5192-#5194) risks being designed twice: once for self-host, once again for hosted, instead of one client shape that serves both.
Area
AMS / Cloud architecture
Proposal
Decide and document which client surfaces a hosted AMS ships, and in what sequence, applying the same "reuse the self-host layer, don't fork it" pattern recommended for the backend: evaluate whether
apps/gittensory-miner-ui(already being hardened for self-host in Wave 4) can become the SAME web dashboard for hosted customers with a hosted-mode config flag (mirroring how ORB's own dashboard already serves both self-host operators and gittensory's own hosted install from one codebase), versus where a genuinely separate mobile app, desktop app, or deeper CLI investment would need net-new work with no self-host equivalent to reuse. Explicitly sequence: what ships for a hosted AMS launch versus what's a later expansion.Deliverables
Resources
gittensory-miner mcpstdio server (bin entry, one health-check tool) #5153 (the new AMS MCP server) — a hosted mobile/desktop client could plausibly be "just another MCP client" rather than a bespoke app; worth evaluating against that option explicitly before committing to native app developmentBoundaries
This issue is a planning/decision issue only — it must not itself start building a mobile or desktop app. Any client-surface work that follows from this decision gets its own separate issue(s), scoped after this one closes. Depends on nothing else in this milestone to START (it can run in parallel with the backend-focused issues), but the control-plane architecture spec in this same milestone should ideally land first so this issue's "reuse plan" can reference an agreed backend shape rather than guessing at one.