Gas City Native-First Operating Model¶

1. Controlling Principle¶

Do not build the factory beside Gas City. Run Bluefly’s real work through Gas City, and only add Bluefly capability where execution proves Gas City or another upstream does not already own it.

Before Bluefly creates any orchestration code, worker abstraction, agent configuration layer, event adapter, skill-distribution mechanism, model router, or custom runtime, agents must inspect the native Gas City capability first.

2. The Five Independent Axes of a Gas City Agent¶

Gas City explicitly models an agent as five independent axes: - Harness: which agent CLI - Model: which model - Upstream: who serves that model - Transport: how Gas City drives the harness - Runtime: where the session executes

These concerns are deliberately independent. Bluefly must not build its own model-routing/configuration layer (e.g., in OpenClaw) merely to switch between endpoints like Claude, Codex, local LM Studio, or LiteLLM. The desired architecture is:

Gas City Agent
 │
 ├── harness = codex / claude / opencode / etc.
 ├── model = task-appropriate model
 └── upstream
      ├── cloud provider
      ├── LiteLLM
      └── local LM Studio

3. Gas City Ownership and Hierarchy¶

Stop treating blucity-packs as "some Bluefly config repo". Packs are the native Gas City portable capability packaging mechanism and can contain agents, prompt templates, providers, formulas, orders, commands, doctor checks, overlays, skills, MCP configuration, and reusable assets.

Ownership Decision Gate:

DOES GAS CITY ALREADY OWN THIS PRIMITIVE?
 │
 ├── YES → configure/import/patch it
 │
 └── NO
      ↓
   DOES ANOTHER MATURE UPSTREAM OWN IT?
      │
      ├── YES → reuse/integrate
      │
      └── NO → smallest Bluefly adapter

The 8-Level Ownership Hierarchy¶

GAS CITY NATIVE PRIMITIVE
GAS CITY FIRST-PARTY PACK
OTHER MATURE UPSTREAM
BLUEFLY CONFIGURATION
BLUEFLY PATCH / OVERLAY
BLUEFLY THIN ADAPTER
BLUEFLY PACK
BLUEFLY CUSTOM SERVICE (Requires highest evidence burden)

4. Upstream Pack Imports and Patching¶

Every new Bluefly pack proposal must prove: PUBLIC_REGISTRY_SEARCHED=YES, FIRST_PARTY_PACK_CHECKED=YES, EXISTING_BLUEFLY_PACK_CHECKED=YES.
When modifying upstream Gas Town behavior, patch the imported pack rather than copying/forking it. Apply city-level or rig-level patches.
Keep truly city-specific roles in the root City pack rather than contaminating/forking the generic upstream pack.
Imports must be pinned (e.g. specific source/version), not floating.

5. Polecat Worker Pools¶

Do not build a Bluefly worker-pool manager. Configure native Polecat pools per rig. - Simple/repetitive work → larger cheap/local Polecat pool. - Specialized or expensive work → smaller pool / different provider. - Standing coordination → named agents only where required.

6. System State Boundaries¶

The separation must remain strict: - pack.toml + pack dirs = portable definition / behavior - city.toml = this City's deployment choices - .gc/ = machine-local bindings and runtime state

Do not confuse machine-local .gc/ state with portable definitions.

Provider Configuration and State Leakage¶

Gas City providers MUST explicitly pin their underlying model defaults (e.g., option_defaults = { model = "sonnet" } for builtin:claude) in the provider configuration. If a model is not pinned by Gas City, the underlying harness may fall back to the host workstation's unmanaged global state (e.g., ~/.claude.json), causing governed executions to leak state and break reproducibility.

7. Machine Automation Contracts¶

Any Bluefly automation, dashboard, hook, test, or agent invoking gc MUST: - Use --json when supported. - Respect process exit code for control flow. - Validate expected fields. - Prefer --json-schema contracts to avoid hard-coded assumptions.

MUST NOT: - Grep human tables. - Regex terminal banners. - Parse spacing. - Depend on prose status messages.

8. External Handshake¶

Before building custom interaction bridges (e.g. Drupal-to-Gas-City), evaluate whether the native external messaging API (extmsg) can fulfill the requirement via HTTP POST/SSE. Decision order: extmsg → MCP → Tool API → Thin adapter → Stop before inventing platform.