/using-gc

name: using-gc
description: 'Operate Gas City through its Mayor, registry packs and native run state. Use when: the caller explicitly selects Gas City; factory completion does not replace independent judgment.'
practices: [team-topologies, design-by-contract]
hexagonal_role: driving-adapter
consumes: [explicit-packets]
produces: [gas-city-runtime-evidence]
context_rel:
- kind: partnership
  with: agent-native
skill_api_version: 1
user-invocable: true
metadata:
  tier: execution
  dependencies: []
  capabilities: [dispatch_explicit_packet, observe_gc_runtime, inspect_pack_registries, drive_mayor_door]
  effects: [operate_gas_city, configure_codex_trust]
  canonical_status: canonical
  disposition: keep_optional_adapter
output_contract: runtime evidence per supplied packet

Using GC

Use Gas City only when the caller explicitly selects it. Treat it as a replaceable execution adapter, not a correctness or completion boundary. The adapter cannot select AgentOps semantics, issue a binding verdict, or turn factory completion into delivery or validation proof.

Choose the factory first

AgentOps supports both Gas City and the [Agentic Coding Flywheel](https://agent-flywheel.com) as external software-factory runtimes. Use this skill only for Gas City. If the caller selects the Flywheel, switch to [using-flywheel](../using-flywheel/SKILL.md) and its native workflow instead of wrapping it in Gas City.

AgentOps supplies skills and evidence contracts to either factory. It does not need its own Gas City formula or role pack. Install or link AgentOps skills into the provider runtime before starting workers; the upstream Mayor, coordinator, and workers can then discover and select `plan`, `implement`, `test`, `validate`, and other AgentOps skills normally.

Gas City 1.4 operating model

Gas City 1.4 is run-centered. The supervisor serves the dashboard and typed, paginated session/run APIs. Every graph-owning city or rig scope needs its own `core.control-dispatcher`; that deterministic worker advances formula control beads. Agent workers claim routed work. The upstream `gc.mayor` skill is the guided coordinator; `gc.run-operator` launches and supervises formulas.

The normal AgentOps path is:

1. Install and pin the upstream `gascity` workflow and rig-role imports. 2. Add the project as a rig, prepare its stock maintainer runtime, and make AgentOps skills visible to its provider sessions. 3. Create a caller-owned source intent bead and hand its id to the Mayor, which authors the workflow beads and dispatches the upstream `build-basic`, continuation, review, or implementation formula that matches the available artifacts. 4. Read run, session, bead, artifact, and verdict state. Completion is never inferred from chat or pane prose.

Prepare and qualify a rig before its first build with the shipped AgentOps CLI (no repo checkout required):

ao gc prepare --city /path/to/city --rig /path/to/rig
ao gc check --city /path/to/city --rig /path/to/rig

The command verifies the exact official workflow and role pins, snapshots the upstream validation scripts and schemas unchanged inside the rig's `.gc` runtime, installs only small AgentOps-owned wrappers at the formula check paths, selects an existing Python that can import PyYAML, and links the AgentOps skills into the city and rig Codex sinks. Skills come from the enclosing AgentOps checkout when one is present, otherwise from the installed skills root; pass `--skills-source` to pin a different directory. It never modifies the GC binary, cache, formulas, roles, or upstream pack. `check` issues only native inspection commands, writes no adapter files, and fails before model spend when that runtime contract is missing or drifted.

`prepare` also pre-seeds Codex trust for every session directory that exists when it runs — the city and rig roots, each `.gc/agents/**` session home, and each rig worktree root — so a Codex session in one of those directories does not block on the interactive trust dialog. Both persisted layers are seeded in `$CODEX_HOME/config.toml`: workspace trust (`[projects."<dir>"] trust_level = "trusted"`), without which Codex silently reports that directory as having no hooks at all, and per-hook trust (`[hooks.state."<hooks.json>:<event>:<m>:<h>"] trusted_hash = "sha256:..."`), which is what the pack's per-provider `.codex/hooks.json` would otherwise prompt for. Hook digests are read back from Codex's own `hooks/list`, never recomputed.

Trust is judged by value, not by the presence of a table. `prepare` appends only entries that are missing and refuses, naming the entry, when one exists but does not confer trust — an explicit `trust_level = "untrusted"`, a hook Codex reports as changed since it was trusted, a recorded hook Codex still rejects, or a hook recorded `enabled = false` (a disabled hook is not a trusted working hook). It never overwrites an operator decision, and re-running is a no-op. It also fails rather than continue if Codex returns an empty or unrecognized hook list. The trust store itself is never edited in place: the merged content is parsed in memory first, then installed with the CLI's durable atomic writer, so no failure path can leave a partially written Codex config.

`ao gc check` verifies the same pre-seed from local state only — it runs no Codex subprocess and writes nothing, deriving each expected hook key from the directory's own `hooks.json` — and names the specific deficient directory or hook using the same rule `prepare` seeds to.

**Two named limitations.**

1. **`check` cannot detect a stale hash.** Because it never asks Codex, a recorded `trusted_hash` that no longer matches the hook's current content reads as satisfied and still raises the trust dialog in a real session. Only `prepare` sees that — Codex reports the hook as changed and `prepare` refuses. A green `check` therefore means "trust is recorded", not "trust is fresh". 2. **Homes created after `pre