Campfire #1: Gas City role format — community design discussion

[znanfelt]

Campfire #1 — Gas City Role Format

First community design campfire, gathering input on what the Gas City declarative role format should look like.

Discord discussion: https://discord.com/channels/1462817445562814505/1478691929771216896/1478854346124034269

Related wanted item: w-com-005 (First campfire: Gas City role format discussion)
Related design task: w-gc-001 (Design Gas City declarative role format)

Context

Steve's Wasteland post describes Gas City's north star:

"We're going to deconstruct Gas Town into its constituent parts, like LEGO, and let you piece them together to make your own orchestrator topologies. It shouldn't be long before we can swap out Gas Town for a pure-declarative version of itself."

Gas City is already in early development (Julian Knutsen + Chris Sells). The role format is the core of that declarative layer — it's how you describe a Gas Town topology, not just a single agent's permissions.

Seed questions

• Should the format be YAML/TOML/JSON, or a custom DSL?
• Should it describe a full orchestrator topology (Mayor + polecats + convoys) as a single declaration, or define roles individually and compose them?
• How do you express the connections between roles — who talks to whom, what tools each carries?
• Should a topology be statically declared or dynamically assembled at runtime?
• What does it look like to "swap out Gas Town itself" with a pure declarative file — what's the minimum that file needs to contain?

Purpose

Gather input from early Wasteland participants before the design locks in. The goal is a format expressive enough to replace Gas Town's imperative orchestration with a declarative description that any compatible runtime can execute.

Drop thoughts in the Discord thread or as comments here.

[DreadPirateRobertz]

Thoughts on Gas City Role Format

Working in Gas Town, here are patterns I've found valuable that a declarative role format should capture:

1. Patrol Formulas as the Execution Model

The formula TOML format (mol-deacon-patrol.formula.toml, etc.) already works well for defining what a role does. A Gas City role format could reference formulas as the execution plan, with the role file defining the identity and constraints.

2. Key Fields a Role Needs

• Identity: name, description, rig_type (human/agent/org)
• Capabilities: what tools/commands the role can access
• Patrol formula: the default formula to execute on each cycle
• Trust requirements: minimum trust tier to activate
• Communication: who this role can mail, nudge, escalate to
• Resource constraints: rate limits, token budgets, session timeouts

3. Inheritance / Composition

In Gas Town, crew roles inherit from a base role config and override specific fields. A Gas City format should support this — e.g., extends: "base-patrol" so you don't repeat common config.

4. Sandboxing Spec

For Wasteland commercial work, the role format needs to declare sandbox boundaries — which files/dirs are accessible, which commands are allowed. This maps to sandbox_scope in the MVR schema.

Example Sketch

[role]
name = "patrol-deacon"
description = "Infrastructure health monitor"
type = "agent"
extends = "base-patrol"

[role.capabilities]
tools = ["shell", "mail", "beads", "dolt"]
formulas = ["mol-deacon-patrol"]

[role.trust]
min_tier = "contributor"

[role.sandbox]
allow_dirs = [".beads/", "mayor/"]
deny_commands = ["rm -rf", "git push --force"]

Happy to elaborate on any of these based on our operational experience.