Alignment: Concept Exploration

Generated 2026-05-24 • Two concept briefs: Personal Workstation + Commercial SaaS

Summary

A persistent Hetzner-powered remote development machine that runs multiple Claude Code and Codex CLI sessions in parallel, controlled from browser or phone. Five integrated surfaces — Agent Board, Terminal, VS Code, Browser Preview, and File Explorer — provide a complete AI coding workstation with zero public inbound access.

This is the personal dogfood environment. It is not yet a product. It exists to prove the workflow, identify pain points, and build the shared codebase that later becomes the commercial SaaS.

Problem Hypothesis

Running AI coding agents locally is constrained by:

Resource limits: laptop CPU/RAM caps out at 3-5 parallel agent sessions.
No mobile access: can't monitor, approve, or review agent work from phone.
No orchestration UX: no unified view of what multiple agents are doing, their status, or their outputs.
Session fragility: closing a laptop kills sessions; tmux helps but has no GUI.
Security gaps: agents run with full local access, no guardrails on sensitive files.

A persistent remote machine solves the resource and access problems. The control surface (Agent Board + supporting apps) solves the orchestration problem.

Beneficiary Hypothesis

The sole beneficiary is you — a solo developer who wants to:

Run 5-12 parallel AI coding sessions across multiple repos.
Monitor and control them from Mac and iPhone.
Keep the machine always-on without tying up a laptop.
Maintain a locked-down security posture.

Single-user product. No multi-tenancy, no team features, no billing.

Product Category Guess

Personal developer infrastructure — a private AI coding workstation.

Comparable to running your own build server or CI machine, but purpose-built for interactive AI agent orchestration rather than batch jobs.

Value Wedge

The differentiator is not "VS Code in browser" or "remote terminal" — those exist. The value is:

Human-in-the-loop multi-agent orchestration from any device.

See all active agent sessions in one view with real-time status.
Start, pause, resume, and kill sessions from browser or phone.
Approve or reject risky actions (package installs, file reads, git pushes).
Preview running apps alongside the agents building them.
Review diffs before pushing.

The Agent Board is the product. Everything else supports it.

Section: Personal — Value Wedge

Q1: For the personal version, should the Agent Board be the primary development focus, or should all five surfaces receive equal priority?

Agent Board first — build the orchestration UX, use existing tools (tmux, code-server) for other surfaces initially Equal priority — all five surfaces should be built together as a cohesive experience Agent Board + Terminal first — the two most critical surfaces, defer VS Code/Preview/Files Other / None of the above

Need clarification

Constraints

Constraint	Detail	Source
Provider	Hetzner Cloud US	Decided
Default machine	CCX33 (8 vCPU, 32 GB RAM)	Decided
Burst machine	CCX43 (16 vCPU, 64 GB RAM)	Decided
Scaling rule	Do not expand root disk on scale-up	Decided
OS	Ubuntu LTS	Decided
Network posture	Zero public inbound ports	Decided
Access layer	Cloudflare Tunnel/Access or Tailscale initially	Decided
Agent CLIs	Claude Code CLI + Codex CLI	Decided
Session management	tmux-based	Decided
Browser IDE	code-server or OpenVSCode Server	Decided
Code structure	Monorepo shared with commercial SaaS	Decided

Section: Personal — Constraints

Q2: Which access layer should the personal version start with?

Cloudflare Tunnel + Access — free tier covers personal use, handles auth and tunneling in one service Tailscale — simpler setup, mesh VPN, free for personal use, but no web-facing URLs for mobile PWA without extra work Both — Tailscale for direct access, Cloudflare for web/PWA endpoints Other / None of the above

Need clarification

Non-Goals

Enterprise compliance or certifications
Multi-user or team features
Kubernetes or container orchestration
Multi-cloud or autoscaling beyond CCX33/CCX43
Native iOS app (PWA only)
Model provider billing or API key resale
Public SSH or publicly exposed web ports
GitHub Actions CI/CD
Full remote desktop experience

Assumptions & Unknowns

Confirmed Assumptions

Hetzner CCX33 provides sufficient compute for 5-10 parallel agent sessions. [from prompt]
Cloudflare Tunnel or Tailscale provides adequate access security for personal use. [from prompt]
tmux is the right session management primitive. [from prompt]
The five-surface model covers the workflow. [from prompt]

Unknowns Requiring Validation

#	Unknown	Risk	Notes
1	Programmatic CLI control	Critical	No known strategy for programmatically starting, monitoring, or controlling Claude Code / Codex sessions. Gates the Agent Board.
2	Permission prompt interception	Critical	Can approval/rejection be intercepted and routed to web UI without forking CLIs?
3	Session state observation	High	How to read real-time status from agent CLIs.
4	Output streaming	Medium	How to stream agent output to web UI in real time.
5	Resource ceiling	Low	Whether CCX33 handles 10+ parallel sessions. Testable empirically.

Section: Personal — Unknowns

Q3: How should the critical CLI integration unknown be investigated?

Technical spike before any UI work — prove feasibility of programmatic CLI control first, then design the Agent Board around what's possible Build Agent Board UI in parallel — use mock data while investigating CLI integration, swap in real data later Start with tmux output scraping — a crude but fast approach to unblock the Agent Board, refine later Other / None of the above

Need clarification

ICP Readiness & Next Steps

ICP Readiness: Not applicable. Single-user personal tool.

Purpose of personal version:

Validate workflow assumptions.
Resolve critical CLI integration unknowns.
Build shared monorepo packages for the commercial SaaS.

Primary recommendation: /pack install business-discovery — install research skills to prepare for the commercial concept.

Other next steps:

Technical spike on CLI integration (feasibility gate).
/feature-interview on the Agent Board once CLI strategy is known.

Summary

A browser/mobile SaaS control plane for AI coding agents running on customer-owned dev machines. Customers install a lightweight host agent on any Ubuntu VPS. The agent connects outbound to the SaaS. Users get five integrated surfaces to orchestrate Claude Code, Codex, and future coding agents remotely.

Optional premium tier: managed Hetzner devbox provisioning for customers who want turnkey infrastructure.

Builds on the personal workstation codebase via a shared monorepo.

Problem Hypothesis

Developers increasingly use AI coding agents but face these problems at scale:

No remote orchestration: agents run in local terminals with no mobile or browser access.
No multi-agent visibility: 5+ agents means 5+ terminal tabs, no unified status view.
No safe approval workflow: permission prompts require physical presence at the machine.
No session persistence: closing a connection loses context.
Security gaps: agents have full machine access, no guardrails.
Setup burden: configuring a secure remote dev environment requires significant sysadmin effort.

Existing browser IDEs solve "code in a browser" but not agent orchestration. T3 Code validates the concept but lacks professionalization.

Beneficiary Hypothesis

Primary (BYO-host SaaS)

Power users / solo founders: already have VPSs, want orchestration without sysadmin overhead.
Freelancers / agency developers: multiple client projects, need session isolation and mobile access.
Security-conscious developers: want zero-inbound architecture, project-scoped access, audit trails.
Small teams: shared visibility into agent work without exposing full machine access.

Secondary (managed IaaS tier)

Non-sysadmin developers: want turnkey devboxes without server setup.

Section: SaaS — Beneficiary Hypothesis

Q4: Which beneficiary segment should ICP analysis prioritize first?

Power users / solo founders — most likely early adopters, already have infrastructure Freelancers / agencies — clear pain point (multi-client), potential for higher willingness to pay Security-conscious devs — strongest differentiator alignment (zero-inbound) Other / None of the above

Need clarification

Product Category Guess

Developer tools SaaS — AI agent orchestration control plane.

Not a browser IDE. Not managed VPS hosting. The VPS is the execution layer; the product is the control plane.

Value Wedge

Human-in-the-loop multi-agent orchestration from browser and mobile.

vs.	Gblock Party advantage
Local CLI usage	Remote access, mobile, multi-agent visibility, session persistence
Browser IDEs (Gitpod, Codespaces)	Agent orchestration focus, not just "code in browser"
T3 Code	Better mobile UX, zero-inbound security, session management, diff review, approval workflow, secrets guardrails
Self-managed VPS + tmux	Turnkey control plane, no sysadmin, Agent Board UX

The product competes on: "I can run 10 coding agents safely, monitor them from my phone, approve risky actions, review diffs, preview apps, and recover when something goes wrong."

Constraints

Constraint	Detail	Source
Build order	Personal workstation built and dogfooded first	Decided
Code structure	Monorepo shared with personal version	Decided
Commercial model	Hybrid SaaS + optional managed IaaS	Decided
Host OS	Ubuntu LTS (initial target)	Decided
Network posture	Host-initiated outbound only	Decided
Agent CLIs	Claude Code + Codex initially, OpenCode later	Decided
Managed infra provider	Hetzner (for optional IaaS tier)	Decided
No GitHub Actions	Project does not use GitHub Actions	Decided

Non-Goals

Full enterprise compliance / certifications (Phase 6)
Kubernetes or container orchestration
Multi-cloud autoscaling
Native iOS/Android apps (PWA only)
Model provider billing or shared API key accounts
Public SSH or publicly exposed web IDE ports
Full remote desktop experience
Root-level browser shell by default

Assumptions & Unknowns

Confirmed Assumptions

Agent Board (multi-agent orchestration) is the core value. [from prompt]
Hybrid SaaS + optional managed IaaS is the best path. [from prompt]
Zero-inbound security posture is a genuine differentiator. [from prompt]
BYO-host SaaS should come before full IaaS. [from prompt]

Unknowns Requiring Validation

#	Unknown	Risk	Category	Notes
1	CLI programmatic control	Critical	Feasibility	No known strategy. Must be resolved during personal dogfood.
2	Permission prompt interception	Critical	Feasibility	Can prompts be routed through web UI without forking CLIs?
3	Session state observation	High	Feasibility	Real-time status from agent CLIs.
4	Host-to-SaaS tunnel	High	Architecture	Technology choice undecided (WebSocket, WireGuard, custom).
5	Willingness to pay	High	Market	$29-79/mo when CLIs are free. Needs ICP validation.
6	Data custody trust	Medium	Market	Trust barrier for security-conscious devs tunneling through SaaS.
7	Host agent reliability	Medium	Engineering	Auto-updates, crash recovery on diverse environments.
8	Multi-agent CLI compatibility	Medium	Feasibility	Whether future agents have similar enough interfaces.

Section: SaaS — Unknowns

Q5: The pricing hypothesis ($29-79/mo BYO-host, $199-499/mo managed) was proposed in the concept document. How confident are you in this range?

Directionally right — validate during ICP but use as starting hypothesis Likely too low — the orchestration value could support higher pricing Genuinely unknown — need market research before anchoring on any range Other / None of the above

Need clarification

ICP Readiness

Ready for ICP once /pack install business-discovery is run.

ICP Inputs

Beneficiary hypotheses: power users, freelancers, agencies, security-conscious devs, small teams.
Value wedge: multi-agent orchestration control plane, not browser IDE.
Pricing hypothesis: $29-79/mo BYO-host, $199-499/mo managed devbox.
Differentiators vs. T3 Code, browser IDEs, raw VPS+tmux.

Assumptions to Test First

CLI programmatic control feasibility (technical spike, not market research).
Whether target users currently run multiple AI agents in parallel.
Whether zero-inbound security posture matters or is table stakes.

Next Steps

Primary recommendation: /pack install business-discovery — install ICP, competitive analysis, value prop, positioning, and lean canvas skills.

Other next steps:

Technical spike on CLI integration (run in parallel with business discovery).
/icp after business-discovery is installed.

Section: SaaS — Next Steps

Q6: What should happen first after these concept briefs are committed?

/pack install business-discovery then /icp — validate market before investing in technical spikes Technical spike on CLI integration — prove feasibility before market research, since a "no" here changes the entire product Both in parallel — business discovery + CLI spike simultaneously Other / None of the above

Need clarification

Concept Exploration: gblock-party

Summary

Problem Hypothesis

Beneficiary Hypothesis

Product Category Guess

Value Wedge

Constraints

Non-Goals

Assumptions & Unknowns

Confirmed Assumptions

Unknowns Requiring Validation

ICP Readiness & Next Steps

Summary

Problem Hypothesis

Beneficiary Hypothesis

Primary (BYO-host SaaS)

Secondary (managed IaaS tier)

Product Category Guess

Value Wedge

Constraints

Non-Goals

Assumptions & Unknowns

Confirmed Assumptions

Unknowns Requiring Validation

ICP Readiness

ICP Inputs

Assumptions to Test First

Next Steps

Compile Answers