Skip to content

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

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

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