Skip to content

Gastown Cloud: Cloud-first rewrite of Gastown as a Kilo platform feature #204

Closed

Description

@jrf0110

Disclaimer: This is completely experimental. We are currently exploring multiple angles for integration.

Overview

Cloud-first rewrite of Gastown's core tenets as a Kilo platform feature (Proposal D — Revised). All orchestration state lives in Durable Objects (SQLite). Agents interact with Gastown via tool calls backed by DO RPCs — no filesystem coordination, no gt/bd binaries. Each town gets a Cloudflare Container that runs all agent processes (Kilo CLI instances) — one container per town, not one per agent.

Product vision: An absurdly simple product. Create a town, connect repos via existing integrations, talk to the Mayor in a chat interface. The full Gastown machine operates behind the scenes — agents spawn, communicate, merge code — and the UI shows everything happening in real time. Every object on screen is clickable, every connection is traceable.

See plans/gastown-cloud-proposal-d.md for the full architecture proposal, UI vision, and architecture assessment.


Workflow

For each sub-issue:

  1. Branch: Create a branch off main using the naming scheme {issue_number}-{short-description}
  2. Implement: Work through the issue's acceptance criteria. Write tests alongside the implementation.
  3. Validate: Run the test suite and type checks (pnpm typecheck) to confirm everything passes.
  4. Commit: Stage all changes and create a commit with a descriptive message referencing the sub-issue number.
  5. Push & PR: Push the branch and create a pull request targeting main. Link the sub-issue in the PR body with Closes #NNN.

Phase 1: Core Loop + Mayor (COMPLETED ✅)

Foundation: Rig DO state machine, HTTP API, tool plugin, container with kilo serve, alarm scheduler, tRPC routes, basic dashboard, MayorDO.

Phase 1.5: Close the Loop + Usable UI (NEW — Priority Sprint)

The core loop is built but doesn't close: the Mayor can't delegate, agents can't be watched, merges 404, and the dashboard is a skeleton. These issues unblock a product that actually works end-to-end.

P0 — Must complete before product is usable:

P1 — High impact, required for decent UI:

Phase 2: Multi-Agent Orchestration (COMPLETED ✅)

All Phase 2 issues implemented in PR #389.

Known issues from Phase 2 testing:

Phase 2.5: Town-Centric Refactor

Simplify the DO topology, replace subprocess-based agent management with the SDK, and establish a clean WebSocket event pipeline. See plans/gastown-town-centric-refactor.md for the full plan.

Phase 3: Multi-Rig + Scaling

Phase 4: Hardening


Future Ideas


Closed/Superseded Issues

Activity

  1. evanjacobson commented on Feb 16, 2026

    @evanjacobson
    Contributor

    This is awesome, I'd love to help.

  2. self-assigned this
    on Feb 19, 2026
  3. 14 remaining items

  4. jrf0110 commented on Mar 9, 2026

    @jrf0110
    ContributorAuthor

    Phase 3 Progress: #901 and #442 landed

    PR #904 merged to main (squash). This completes two Phase 3 sub-issues:

    #901 — Feature Flags & Progressive Rollout ✅

    • PostHog feature flag integration for gastown access gating
    • isGastownEnabled() with dev override
    • Replaces binary is_admin gate on all gastown routes and pages

    #442 — Witness & Deacon: Alarm-Driven Orchestration ✅

    • Tiered GUPP violation handling (30min warn → 1h escalate+triage → 2h force-stop)
    • On-demand LLM triage agent for ambiguous situations (stuck agents, crash loops, escalations)
    • Per-bead timeout enforcement with container termination
    • Container eviction recovery (404 → not_found → immediate redispatch)
    • Orphaned work detection, stale hook recovery, agent GC, crash loop detection
    • Mayor codebase browsing via browse worktrees + AGENTS.md propagation to sub-agents
    • Proactive repo cloning on rig creation and mayor startup
    • Escalation→triage pipeline with convoy context tracking
    • Refinery per-rig singleton with proper rollback on failure
    • Real-time alarm status UI with WebSocket + polling fallback
    • Convoy title/branch flex truncation, status pane padding normalization
    • Rig deletion fix (tRPC path now cleans up TownDO registry)

    New sub-issue created

  5. jrf0110 commented on Mar 16, 2026

    @jrf0110
    ContributorAuthor

    #447 — Cloud-Unique Capabilities: UI-Aware Mayor (Phase 1) shipped in #1123

    Implemented the first feature from the future ideas list: Dashboard Context Injection + UI Action Control for the mayor. The mayor now has awareness of what the user is viewing and can control the dashboard (open drawers, navigate pages).

  6. jrf0110 commented on Mar 23, 2026

    @jrf0110
    ContributorAuthor

    📋 This issue is now retired as an active tracking tool.

    Phases 1-3 and Phase 2.5 are complete. Phase 4 (Hardening) items have been triaged into milestone-based tracking:

    Milestone Purpose Link
    gastown-soft-launch Everything required before real users Milestone 1
    gastown-post-launch Polish and features for first 2-4 weeks Milestone 2
    gastown-future Speculative / long-term / no timeline Milestone 3

    New labels for filtering:

    • Area: gt:core, gt:container, gt:refinery, gt:ui, gt:onboarding, gt:billing, gt:mayor, gt:observability
    • Priority: P0 (blocks launch), P1 (should fix before launch), P2 (post-launch), P3 (backlog)

    All new gastown work should be filed as standalone issues with the appropriate milestone and labels. Do not add items to this issue's body.

    This issue remains open as a historical reference for the architectural roadmap and completed phases.

  7. pinned this issue on Mar 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions