Skip to content
gemba

Gas Town adaptor

Gas Town adaptor

Status: shipping (gm-e7.x epic)

Transport

The Gas Town adaptor declares transport: "api" (HTTP+JSON request/response per gm-root DD-12). v1 the API channel is the local gt CLI invoked with --json:

gt rig list --json     →  []rig{...}
gt polecat list --json →  []polecat{...}
gt mail inbox --json   →  []mail{...}
gt session ...

Every adaptor method is a one-shot JSON request/response cycle. Functionally equivalent to a remote HTTP+JSON service — the adaptor body just happens to reach the local gt process via exec. A future remote shim that POSTs the same payloads to a Gas Town daemon (gemba adaptor register --transport api --target https://gastown.example.com) can replace the exec runner with a fetcher and the adaptor body stays unchanged.

No MCP bridge required. MCP is recommended-not-required per DD-15; the adaptor has no MCP surface today.

First-class boot model

Gas Town mode separates the two planes:

  • WorkPlane / Beads: pass a Dolt server URL with --dolt-url or --beads-url, for example mysql://root@127.0.0.1:3307/gemba.
  • OrchestrationPlane / runtime: pass --orchestration=gastown plus --city <path> or legacy --town <path>. Every gt shellout runs with that directory as cwd.

Example:

Terminal window
gemba serve \
  --dolt-url 'mysql://root@127.0.0.1:3307/<beads-db>' \
  --orchestration=gastown \
  --city <gas-town-root>

Do not pass a Gas Town rig as --project-dir. A rig is a code/runtime scope owned by Gas Town; the Beads database is served by Dolt.

Workspace and dispatch mapping

Gemba imports existing rigs from gt rig list --json. Each rig becomes a Gemba workspace/scope. When the CLI exposes repository, branch, or worktree_path/path/dir, the adaptor copies those fields into core.Workspace so source-analysis status, dirty-tree checks, and evidence links point at the real rig checkout.

Session dispatch uses Sling:

StartSession(bead, target_rig=rig) -> gt sling <bead> <rig> --agent <agent> --create

The server now threads the selected workspace as gemba:target_rig, so dragging a bead, epic, or milestone from a scoped board dispatches to the intended rig rather than whatever rig happens to be listed first.

Interactive project onboarding uses the Gas Town root to reuse or create the selected rig, then writes Gemba/LLM setup files into the rig worktree. It records the Dolt Beads URL in .gemba/workspace.toml and requests an onboarding crew first, falling back to an onboarding polecat when the installed gt does not support crew creation.

Manifest

adaptor_id              = "gastown"
adaptor_version         = "0.1.0"
transport               = "api"
workspace_kinds         = ["worktree"]
default_workspace_kind  = "worktree"
group_modes             = ["static", "pool"]
cost_axes               = ["wallclock"]   # gm-e7.4 expands this
escalation_kinds        = ["hitl_approval"] # gm-e7.5 expands this
peek_modes              = ["transcript"]
event_delivery          = "poll"

The cost axes and escalation kinds are intentionally small in v1 — gm-e7.4 (cost meter synthesis) and gm-e7.5 (escalation mapping) expand them as those beads land.

Operator commands

# Register the adaptor
gemba adaptor register --transport api --target gastown


# Inspect manifest
gemba adaptor describe gastown


# Watch live polecat status
gt polecat list --all --json | jq .

Conformance

Group A (Describe + Capability) passes today. Groups B–F land as the rest of the gm-e7.x sub-beads ship; gm-e7.7 is the conformance gate.

See also

  • gm-e7.1 — list_agents / list_groups
  • gm-e7.2 — start_session / stop_session / claim_next_ready
  • gm-e7.3 — session lifecycle + tmux capture-pane peek
  • gm-e7.4 — cost meter synthesis
  • gm-e7.5 — escalation mapping (gt escalate → EscalationRequest)
  • gm-e7.6 — this file: transport: api declaration
  • gm-e7.7 — conformance suite