Skip to content

THE GOVERNED PRODUCT FACTORY

Gas City Official Documentation Update

Corrected architecture, remote operating model, productization, monetization, and Drupal modernization strategy

Prepared for Bluefly.io, LLC\ Thomas Scola\ 3 August 2026

Revision authority
This edition uses the user-supplied July 22 research as the working base, but replaces claims contradicted by the current official Gas City documentation. It distinguishes upstream Gas City facts from Bluefly-specific architecture, standards, product choices, and commercial recommendations.

Executive decision

Gas City is the platform for building software factories. It is not a light supervisor sitting above Gas City as a separate dark runtime. Gas City is now one opinionated orchestration expressed through configurable Gas City packs. The platform itself hardcodes no Mayor, Deacon, Witness, Refinery, Polecat, Crew, reviewer, planner, or manager role.

The correct customer strategy remains strong: Bluefly should not sell Gas City, agents, tokens, or prompt orchestration. Bluefly should use Gas City privately to manufacture and continuously operate customer-owned, Drupal-based digital service products. The commercial unit is a governed modernization outcome with acceptance evidence, recurring assurance, and legacy disposition.

Primary correction
Replace “Gas City = Light Factory and Gas City = Dark Factory runtime” with: “Gas City is the role-agnostic orchestration platform; Gas City is a reference configuration/pack built from Gas City primitives. A dark factory is an operating mode or outcome, not a second runtime layer.”

What changed since the prior edition

Area Prior framing Corrected current framing
Core model Large primitive inventory mixed platform mechanisms, Gas City vocabulary, and Bluefly concepts. Six canonical primitives: Agent, Bead, Formula, Rig, Pack, Event. Sessions, orders, convoys, drain, waits, patrol, sling, providers, and supervisor are mechanisms built around them.
Gas City relationship Gas City described as a runtime underneath Gas City. Gas City roles and behaviors are configuration. Gas City extracted the machinery and can express Gas City, Ralph, or other orchestrations.
Roles Mayor, Deacon, Witness, Refinery, Polecat, Crew, Dog treated as native platform roles. They are optional pack-defined agents or operating styles. Deacon watchdog behavior is largely orchestrator patrol/reconciliation, not an LLM role.
State Each rig described inconsistently as having a separate database. A city and rigs can share one underlying store while logical isolation is enforced through bead-ID prefixes and scope filtering. Quickstart language should be read alongside the internal topology reference.
Packs Directory of prompts plus topology. Portable behavior definition including agents, prompts, providers, formulas, orders, commands, doctor checks, overlays, skills, MCP settings, defaults, named-session settings, and assets.
Remote use Mostly SSH/tmux attachment. The supervisor exposes a typed HTTP+SSE API, built-in dashboard, external-client messaging, contexts, and a hardened remote-write pattern. SSH remains an operator path, not the sole client model.
Security Remote exposure treated as simple zero-trust networking. Imported packs and configured commands are trusted code, not sandboxed content. Hardened direct cities expose an unauthenticated read plane and therefore require a network front plus signed write grants.
Productization Packs presented as sellable by themselves. Packs are internal product assets. Customers buy governed service outcomes; reusable packs reduce cost, risk, lead time, and upgrade burden.

Part I — The official Gas City model

1. The machinery underneath

Machinery Responsibility What it deliberately does not know
Orchestrator Runs formulas, advances bead graphs, reconciles declared agents and live sessions, retries and restarts according to policy. It has no built-in manager, reviewer, planner, Mayor, Deacon, or other business role.
Bead store Durable ground truth for work, dependencies, messages, sessions, convoys, and lineage. It does not infer completion from a chat transcript or process lifetime.
Event bus Emits immutable, append-only activity records with replayable sequence numbers. Events are observation records, not the authoritative work objects themselves.
Supervisor Hosts and manages registered cities, API, SSE streams, dashboard, and service lifecycle. It does not replace repository, CI, release, deployment, or product governance systems.

2. The six canonical primitives

Primitive Question Authoritative meaning Bluefly usage
Agent WHO Configured worker: name, provider, prompt template, scope, scale and session behavior. A running agent is a session. Define narrow roles in packs; use pools only where work demand justifies parallelism.
Bead WHAT Universal durable unit with ID, title, status and type. Tasks, mail, sessions and convoys are bead types. One authoritative work substrate; map customer commitments and GitLab evidence into it rather than creating a shadow planner.
Formula HOW Reusable TOML method. V2 compiles steps and dependencies into a graph of beads run outside any single session. Encode verified modernization molecules, review lanes, migration flows, release assurance and recurring maintenance.
Rig WHERE Registered external project, usually a Git repository, with bead namespace and agent scope. One canonical rig identity per repository; do not confuse path, repo identity, product identity, or customer identity.
Pack CONFIGURES Portable configuration unit declaring agents, formulas, orders and support assets. The city is the local root pack. Keep Bluefly reusable behavior in versioned packs; keep deployment bindings in city.toml and machine-local state in .gc/.
Event OBSERVE Immutable outbound notification from city activity; replayable by sequence number and usable by humans, hooks and event-triggered orders. Project events into observability and evidence, but preserve beads, GitLab and deployment receipts as their respective authorities.

3. Important mechanisms that are not extra primitives

Mechanism Correct interpretation
Session Live process incarnation of an agent. Disposable and adoptable after supervisor restart; work survives in beads.
Order Trigger plus action. Formula orders instantiate agent-driven work; exec orders run operator-side commands. Triggers may be cron, cooldown, condition, event or manual.
Convoy Container bead grouping related work and lineage. It is not a separate orchestration runtime.
Drain V2 formula construct that fans convoy members into item workflows, with shared or separate context and explicit access/failure policy.
Sling Dispatch operation that creates/routes work or routes an existing bead to an agent or formula target.
Health patrol Orchestrator mechanism for stall detection, restart/backoff and desired-state reconciliation. It replaces much of what the Gas City Deacon role embodied.
Wait / needs edge Durable dependency or gate. A blocked bead is withheld from agents until its blockers close.
Provider Implementation behind a session or bead store. Built-in and external providers must be treated as explicit trust and compatibility boundaries.
City The local root pack plus city.toml deployment configuration and .gc machine-local bindings/runtime state.

4. Gas City translated accurately

Gas City concept Gas City expression Bluefly implication
Mayor Configured coordinating agent and prompt, optionally imported from the Gas City pack. Use only when it adds real coordination value; do not make every task flow through a ceremonial Mayor.
Deacon Health patrol, reconciliation and thresholds; optional agent only for work needing reasoning. Operational recovery should be deterministic first and model-assisted second.
Witness Events, waits, formula/session state and optional pack behavior. Do not keep a standing witness merely to mirror legacy topology.
Refinery Configured agent plus post-processing formula/order step. Make integration a bounded workflow with acceptance gates, not a permanent mystical stage.
Polecat Transient/scalable agent pool, often isolated by worktree or provider. Scale from bead demand with min/max session bounds.
Crew Persistent named agent configuration. Reserve persistence for continuity that survives multiple tasks.
Dog Often core exec orders; use an agent only when relay work requires reasoning. Prefer deterministic integrations over paying an LLM to move messages.

5. Packs as reputable reusable product assets

A Gas City pack is not a product merely because it can be imported. It becomes a product-grade asset when it is portable, pinned, reviewable, testable, supported, versioned, diagnosable, recoverable and attached to a narrow outcome.

Concern Required product discipline
Definition/deployment seam pack.toml and conventional pack directories define reusable behavior; city.toml defines this deployment; .gc contains local bindings and runtime state.
Names and scope Use import bindings and rig prefixes deliberately. A city-scoped imported agent and a rig-scoped imported agent have different qualified runtime identities.
Supply chain Pin source and compatible version, verify provenance, review scripts and commands, publish SBOM/checksum/attestation where distributed.
Trust Treat pack commands, provider scripts and startup hooks as executable trusted code. Untrusted bead/API text must never be concatenated into shell.
Compatibility Declare minimum gc/formula compiler/provider versions and test the supported matrix.
Verification Golden fixtures, clean-city install, formula compilation, failure injection, upgrade/downgrade, restart/adoption, recovery and cost tests.
Operations Doctor checks, health signals, disk growth controls, backup/restore, Dolt maintenance, event retention and observable run state.
Commercial boundary The pack remains Bluefly production IP or open-source contribution. The customer purchases the maintained digital service outcome and operational assurance.

6. Formula v2 as the modernization assembly line

Formula v2 is the critical productization primitive because it turns a written method into a durable graph the orchestrator drives outside a session. Ready steps can fan out across agents; dependencies gate subsequent work; failures can be retried; drains can execute per-member workflows; and orders can schedule or trigger the entire method.

Modernization molecule stage Formula responsibility Acceptance evidence
Discover Inventory service, users, content, interfaces, policies, accessibility failures and legacy dependencies. Signed inventory, source links, owner confirmation, risk register.
Model Select Drupal core/contrib/recipe/component/ECA/tool boundaries and identify irreducible gaps. Architecture decision, ownership ledger, no-duplicate check.
Compose Create/apply recipe, configuration, components and smallest adapters. Clean install from declared dependencies and source.
Migrate Map and transform authoritative legacy content/data. Counts, exceptions, hashes, reconciliation report.
Verify Run accessibility, security, behavior, content and policy checks in parallel lanes. Machine results plus human acceptance decisions.
Release Commit, MR, CI, review, merge, package and deploy through GitLab. Immutable chain-of-custody references.
Prove Run production verification and publish runtime/evidence receipt. Deployment identity, test results, approver and timestamp.
Dispose Archive, redirect, revoke and retire legacy surface. Decommission confirmation and cost/risk removed.
Operate Orders generate recurring inspection and improvement work. Trend, SLA, open risk, release and evidence reports.

Part II — Remote production architecture

7. Correct Oracle/workstation topology

Location Authority and responsibilities Access pattern
Oracle production city Authoritative supervisor, root city pack/deployment, registered rigs, durable bead/Dolt services, long-running sessions, formula runs, events and operational endpoints. Managed service plus restricted CLI/API administration; no uncontrolled manual mutation.
GitLab Source, branches, MRs, CI, packages, releases, approvals and deployment chain of custody. Agents and humans use scoped tokens/SSH; all accepted change enters through protected workflows.
NAS Backups, mirrors, archives, curated standards and recoverable assets. Replication and recovery; not a second supervisor or active scheduler.
Developer workstation IDE, review, local testing, optional local provider, gc client/context, dashboard access and SSH break-glass. Remote API/SSE or SSH tunnel/Tailscale; no duplicate authoritative city.
Drupal environments Customer-facing product runtime, content/workflow authority, APIs and product evidence views. Deployment pipeline and narrow service integrations; not engineering orchestration authority.

8. Remote hardening requirements

  • Expose the supervisor only behind Tailscale, a private reverse proxy, or another authenticated network front. The official hardened direct-city runbook explicitly states that the read plane is unauthenticated.

  • Use signed, request-bound X-GC-City-Write grants for remote mutations. Protect the private signing key as production infrastructure authority.

  • Pin and review imported packs before use in a privileged city. Pack code is trusted dependency code, not untrusted content.

  • Pass bead titles, descriptions, mail, formula variables, PR text and API fields as structured data, stdin, JSON, environment variables or argv; never interpolate them into shell command strings.

  • Keep the built-in dashboard on the supervisor listener and expose it through the same private network boundary. One supervisor can present all registered cities.

  • Use the typed OpenAPI 3.1 API and SSE streams for connected clients and automation. Do not create a parallel proprietary control API unless a missing capability is proven.

  • Automate backup cleanup and Dolt bloat recovery as explicit runbooks and monitored capacity thresholds, not tribal commands.

  • Verify release checksums, GitHub attestations and SBOM assets for direct installations; pin the operational version and test upgrades before production.

9. Multi-developer workstation use

  1. Developer authenticates to the private Oracle network and selects a named gc context for the production or non-production city.

  2. Developer inspects live state through gc, the typed API, event stream or dashboard rather than reading server directories as an API.

  3. Work begins as an authorized bead linked to the correct rig and acceptance outcome.

  4. Gas City routes the work to a configured agent/session provider. Local workstation execution is used only when explicitly selected by provider design.

  5. Agents create isolated branches/worktrees and push to GitLab; developers review MRs and CI from their normal workstation tooling.

  6. External clients may register, subscribe by SSE and send turns over HTTP when interactive participation is required.

  7. No workstation owns unique city truth. Losing or replacing a laptop must not lose work state, deployment state or product history.

Part III — Bluefly architecture boundaries

10. Upstream facts versus Bluefly-owned layers

Layer Status Rule
Gas City six primitives, supervisor, providers, packs, formulas, events Upstream fact Adopt terminology and contracts exactly; contribute general improvements upstream.
Gas City pack and role mythology Upstream optional configuration Use selectively; do not reify legacy roles as architectural requirements.
GitLab delivery chain Bluefly operating decision Adapt GitHub-oriented examples at the integration boundary without forking Gas City core.
Oracle authoritative runtime Bluefly deployment decision Maintain through infrastructure/release control; never claim it is required by Gas City.
NAS durable storage role Bluefly operating decision Keep recovery and archive responsibilities explicit and separate from orchestration.
OSSA, DUADP, ContractPlane, ContextControl, Agent Blu Bluefly standards/products Do not describe them as Gas City upstream primitives or dependencies unless an actual adapter/import exists.
Drupal product plane Bluefly product strategy Gas City manufactures and maintains it; Drupal does not become the engineering scheduler.
Light Factory / Dark Factory language Strategic metaphor Use carefully as a visibility and operating-mode metaphor, not as a false two-runtime diagram.

11. Corrections required in the supplied July 22 draft

Draft claim Disposition Replacement
“Gas City is the Light Factory and Gas City is the Dark Factory runtime beneath it.” Replace Gas City is the role-agnostic platform. Gas City is an opinionated pack/configuration. Dark factory describes autonomous operating mode, not a separate runtime.
Gas City primitive list includes City, Session, Provider, Molecule, Wisp, Convoy, Mail, Wait, Order, Sling, Patrol, Gate, Hook, Skill, Prompt, Supervisor. Reclassify Only Agent, Bead, Formula, Rig, Pack and Event are canonical primitives. The others are mechanisms, artifacts, bead types or Bluefly concepts.
Deacon, Witness and other Gas City roles are platform architecture. Replace They map onto configurable agents and first-class mechanisms. Watchdog/reconciliation is orchestrator machinery.
Dolt version-controls every granular agent action and can instantly roll back an AMCS corruption. Narrow Dolt/Beads preserve work-state history and support recovery patterns. Product code, Drupal config/content and runtime deployments each require their own authoritative versioning and restore controls.
OSSA is a universal transport protocol and DUADP is a deterministic deployment pattern. Correct against Bluefly specs These definitions conflict with Bluefly’s own established naming: OSSA defines portable agent contracts; DUADP is agent discovery. Neither is a native Gas City primitive.
Panaversity business plugins are part of the Bluefly Factory architecture. Remove unless adopted Third-party examples are not architecture dependencies without verified integration, ownership and support decisions.
GitHub Agentic Workflows are integrated into the production architecture. Mark optional/unestablished GitLab is authoritative. GitHub workflows may be researched or used upstream but are not assumed production dependencies.
Three-VM Oracle design and listed node/IP state are current architecture facts. Verify separately Runtime inventory is time-sensitive and should live in a dated operational source, not in the evergreen methodology document.

Part IV — Modern Drupal CMS and net-negative coding

12. Drupal’s role in the factory

Drupal is the durable customer product and business authority for structured content, workflows, permissions, revisions, publishing, APIs, components and operational interfaces. Gas City is the engineering factory that composes, tests, upgrades and improves those products. The integration is powerful precisely because the two authorities remain separate.

Need Lowest-ownership Drupal solution Gas City factory behavior
Industry capability Recipe that installs modules and applies configuration/actions/default content. Formula validates recipe on a clean project, tests update behavior and opens an MR.
Polished product starting point Site/project template composing recipes, theme/components and operating documentation. Pack instantiates, verifies and upgrades the template across customer rigs.
Editorial presentation Canvas and reusable accessible components/design tokens. Visual regression, accessibility and component contract lanes.
Business workflow Core workflow/content moderation plus ECA/Modeler where appropriate. Generate and test configuration; do not replace ECA with custom event-subscriber glue.
Agent-operable capability Drupal AI provider abstraction, AI Agents and typed Tool API/MCP boundaries where mature and justified. Pack tests permissions, tool contracts, approvals, failure behavior, evidence and cost.
Integration gap Smallest plugin/adapter using Drupal APIs and contract tests. Dedicated formula lane proves upstream alternatives were considered and adapter ownership is bounded.
Compliance evidence Structured entities/revisions/logs and views fed by authoritative events/receipts. Project Gas City/GitLab/deployment evidence; do not duplicate the work scheduler inside Drupal.

13. Net-negative coding gate

  1. Core first: configure Drupal core and contribute defects upstream.

  2. Security-covered contrib second: adopt and participate in the owning project.

  3. Recipe/configuration third: compose capability declaratively.

  4. Component/ECA/tool configuration fourth: use the framework-native extension point.

  5. Small adapter fifth: write only the irreducible boundary with contract tests.

  6. Upstream extension sixth: contribute broadly useful capability to the owner project.

  7. Custom product code last: require an ADR, differentiated value, maintainer, threat model, tests, telemetry, upgrade budget and deletion trigger.

  8. Delete promptly when upstream replaces the custom implementation.

Ownership equation
Custom code is justified only when expected differentiated value exceeds implementation + review + security + accessibility + test + upgrade + operations + documentation + incident + eventual removal cost. Agent-generated code does not make those costs disappear.

Part V — What customers purchase

14. Product category

Bluefly should sell a governed digital service modernization product, not an AI site builder and not an agent orchestrator. The product converts a bounded legacy service into an accessible, maintainable, evidence-producing Drupal service and then keeps it continuously healthy.

Customer promise
We modernize a priority digital service, prove that it meets its acceptance and governance obligations, retire the legacy burden, and operate the resulting customer-owned platform with continuously visible evidence.

15. Product family and commercial packaging

Offer Customer purchase Acceptance boundary Revenue model
Modernization Readiness Service inventory, user/journey analysis, accessibility and technical baseline, target architecture, ownership model and fixed implementation proposal. Named service, owners, risk, disposition path and measurable acceptance criteria. Fixed fee: \$18K–\$35K planning range.
Modernization Lane Pilot One complete priority service converted end-to-end and legacy path retired or formally dispositioned. Production service, evidence packet, customer acceptance and retirement proof. Fixed fee: \$75K–\$150K planning range.
Service Portfolio Modernization Multiple journeys, migrations, integrations and shared platform capability. Portfolio milestones and service-by-service acceptance. \$200K–\$1.2M+ depending scope and risk.
Foundation Operate Security/update/release management, accessibility regression, monitoring, evidence and improvement capacity. Monthly SLO, release, risk and evidence report. \$8K–\$35K+ monthly planning range.
Expansion Pack New industry journey, department, workflow or integration added to the maintained foundation. Installable/reusable capability plus production adoption. \$15K–\$60K per expansion.
Shared District Edition Common maintained foundation with isolated organizational configuration/content and pooled assurance. Tenant isolation, shared release train and organization acceptance. Onboarding plus \$3K–\$10K monthly per organization.

16. First vertical: public utilities and special districts

A strong first vertical is bounded public-service operators—water, wastewater, transit, housing, authorities and special districts—because their digital obligations are concrete, their service catalogs repeat, their teams are small, and modernization can be demonstrated through complete journeys rather than broad “transformation.”

Initial product module Customer-visible outcome Reusable Drupal assets Reusable Gas City assets
Service Guidance Residents find authoritative eligibility, process, fees, documents and timelines. Structured service type, taxonomy, components, search and guidance recipe. Inventory, content normalization, citation and review formula.
Accessible Application Resident submits an accessible request/application with clear status and notifications. Forms, workflow, moderation, ECA, notifications, integrations. Build/test/migration/accessibility/release lanes.
Public Notice and Meeting Compliant notices, agendas, minutes, documents and subscriptions. Public meeting recipe, media/document policy, subscriptions. Publication assurance and recurring audit order.
Incident and Advisory Authorized teams publish time-sensitive advisories across channels. Advisory model, approvals, expiry, feeds and components. Fast-lane formula with approval and rollback gates.
Policy-to-Service Update New regulation or policy is traced to affected content, workflow, tests and evidence. Policy references, structured change records and views. Impact-analysis formula and evidence-producing release run.

17. Why the customer renews without captivity

  • The customer owns repository, data, content, configuration, customer-specific code, documentation, deployment manifests and export paths.

  • Bluefly earns renewal through maintained capability: release assurance, security, accessibility regression, evidence, incident response, integration health, roadmap upgrades and continuous service improvement.

  • Reusable packs and recipes lower Bluefly delivery cost while improving the customer’s upgrade position. They must not become hidden proprietary lock-in around an otherwise open platform.

  • Exit assistance and a tested handoff procedure are part of product credibility. A customer that can leave is more willing to buy a high-trust managed service.

18. Pricing logic and unit economics

Price driver Why it matters
Number and complexity of service journeys Better correlates with delivered customer value than page count or developer hours.
Integration and data risk Legacy systems, identity, payments, records and migrations drive verification and incident exposure.
Governance/evidence obligation Accessibility, retention, approvals, public records and audit exports create recurring assurance work.
Availability and response tier Operational staffing and response commitments must be funded explicitly.
Release/change cadence More change requires more verification, coordination and evidence.
Shared reuse credit Reusable product capability should increase Bluefly margin and may fund lower customer entry prices without turning engagements into hourly work.
Compute/model consumption Internal cost to meter and optimize, not the primary customer value metric or invoice unit.

Part VI — Execution recommendation

19. Ninety-day proof plan

Window Outcome Required proof
Days 1–15 Correct architecture and runtime baseline. Official terminology adopted; unsupported claims removed; Oracle city inventory verified; version/dependency/security baseline recorded.
Days 16–30 One supported pack and one formula v2 modernization molecule. Clean import, pinned dependency, doctor checks, restart/adoption test, generated bead graph and evidence map.
Days 31–50 One Drupal capability productized. Clean template install, recipe/component/workflow tests, custom-code ownership ledger and upstream contribution plan.
Days 51–75 One real service converted in non-production. Migration reconciliation, accessibility/security/behavior results, GitLab chain of custody and customer-reviewable demo.
Days 76–90 Production pilot and commercial proof. Acceptance, deployment receipt, legacy disposition decision, monthly operate report, case study economics and repeatable sales scope.

20. Operating metrics

Metric Reason
Ready beads → accepted MRs → verified deployments Measures actual factory throughput, not agent activity.
Lead time per modernization molecule Shows whether the reusable method is improving.
Legacy surfaces retired Proves modernization removes cost rather than layering new systems.
Custom code added, avoided, upstreamed and deleted Makes net-negative coding economically visible.
Pack/recipe reuse across rigs and customers Separates product economics from project economics.
Human interventions per accepted run Measures orchestration quality without pretending humans disappear.
Defect escape, rollback and failed acceptance rate Protects reliability from velocity theater.
Compute/model cost per accepted outcome Controls internal factory economics.
Evidence completeness Confirms each claim has source, test, approval, release and runtime proof.
Gross margin by offer and reusable asset Validates monetization and product leverage.

21. Final recommendations

  1. Adopt the official six-primitive vocabulary everywhere and reclassify legacy Gas City terms as pack behavior or mechanisms.

  2. Stop describing Gas City as a separate runtime layer beneath Gas City.

  3. Use the Gas City pack as an optional reference configuration, not as an unquestioned mandatory topology.

  4. Keep the Oracle city authoritative; provide developers controlled gc contexts, dashboard/API access and normal GitLab workflows.

  5. Treat imported packs and configured commands as trusted code with supply-chain review, version pinning and tests.

  6. Use formula v2 to encode the complete modernization molecule, including legacy disposition and evidence—not only feature implementation.

  7. Keep OSSA, DUADP, ContractPlane, ContextControl and Agent Blu explicitly Bluefly-owned and integration-based; do not present them as upstream Gas City architecture.

  8. Pair reusable Gas City packs with Drupal recipes/templates/components and a commercial operating contract.

  9. Sell a customer-owned governed service outcome and recurring assurance, not Gas City seats, tokens or agents.

  10. Prove one public-service modernization lane end to end before expanding the product catalog.

Source and evidence notes

Primary user-supplied revision base: “THE GOVERNED PRODUCT FACTORY — Gas City, Gas City, and Modern Drupal CMS,” supplied 3 August 2026. Claims retained from that draft are treated as Bluefly strategy unless independently supported by current upstream documentation.

1. Gas City Docs — How Gas City Works: https://docs.gascity.com/getting-started/how-gas-city-works

2. Gas City Docs — Coming from Gas City: https://docs.gascity.com/getting-started/coming-from-gascity

3. Gas City Docs — Installation: https://docs.gascity.com/getting-started/installation

4. Gas City Docs — Quickstart: https://docs.gascity.com/getting-started/quickstart

5. Gas City Docs — Web dashboard: https://docs.gascity.com/getting-started/dashboard

6. Gas City Docs — Understanding Packs: https://docs.gascity.com/guides/understanding-packs

7. Gas City Docs — Understanding Formulas: https://docs.gascity.com/guides/understanding-formulas

8. Gas City Docs — Create and Share Packs: https://docs.gascity.com/guides/shareable-packs

9. Gas City Docs — Multi-Agent Engineering Environment: https://docs.gascity.com/guides/multi-agent-engineering-environment

10. Gas City Docs — Connected Clients: https://docs.gascity.com/guides/connected-clients

11. Gas City Docs — Remote Hardened City: https://docs.gascity.com/runbooks/remote-hardened-city

12. Gas City Docs — Command Execution Trust Boundaries: https://docs.gascity.com/reference/trust-boundaries

13. Gas City Docs — Supervisor REST API: https://docs.gascity.com/reference/api

14. Gas City Docs — Configuration Reference: https://docs.gascity.com/reference/config

15. Gas City Docs — Pack Specification: https://docs.gascity.com/reference/specs/pack-spec

16. Gas City Docs — Formula v2 Specification: https://docs.gascity.com/reference/specs/formula-spec-v2

17. The City Wire — Gas City blog: https://blog.gascity.com/

Research status: official Gas City documentation and blog reviewed on 3 August 2026. Gas City and its dependencies are moving quickly; production execution should verify installed versions, generated schemas, release artifacts and current runbooks before applying commands.

22. Drupal → Gas City integration concept (recipe_blucity / blucity-packs / ddev-gascity), revised 2026-09-03

Implements recommendation 23 above ("pair reusable Gas City packs with Drupal recipes/templates/components") as a concrete three-repo wiring. This revision supersedes the earlier same-day version: it re-verifies every internal-repo claim against live GitLab state, corrects several details the first pass got wrong or left unverified, and folds in the fuller architecture concept in §23. Every factual claim below is tagged RETRIEVED (confirmed live), NOT_FOUND (checked, absent — aspirational), or UNKNOWN (external upstream claim, not independently re-verified this session), per this repo's Authority Model (Engineering-Standard/architecture/ — not touched by this edit).

The three repos and what each one owns today (re-verified 2026-09-03):

Repo RETRIEVED state Owns
blueflyio/agent-platform/drupal/recipes/recipe_blucity RETRIEVED: real GitLab project. Its history is exactly one commit — chore: initialize release branch (Thomas @ Bluefly.io, 2026-06-25). NOT_FOUND: no recipe.yml, no composer.json, no files of any kind — list_repository_tree on the repo root returns "not found" even pinned to that exact commit SHA, confirming a genuinely empty tree (not a branch-naming artifact). The claimed module list (node/media/taxonomy/text/options/datetime/link/token/content_moderation/workflows/key) does not exist inside this repo; it is real, but lives elsewhere (see DRUPAL-AUTHORITY-MAP.md below) and is not yet expressed as this recipe's actual dependency list. Intended: the Drupal-native artifact — recipe.yml + composer.json, installable via composer require / drush recipe:apply. Not yet built.
blueflyio/blu/blucity-packs RETRIEVED: large, active monorepo on release/v0.1.x (this session again used that branch, per the prior session's finding that the populated tree lives there). Root pack.toml exists (schema 2, name = "blucity-packs", version = "0.2.0") and enumerates ~30 [imports.*] entries spanning foundation-*, platform-* (incl. platform-gascity, platform-openclaw, platform-beads), knowledge-*, delivery-*, drupal-* (core/ai/content/migration/seo/accessibility/search/workflows/recipes), industry-* (government/healthcare/higher-ed/legal/association), plus amcs, bluguide, organization, governance (repository-governance), digital-service-baseline, kingstown-core, lextown-criminal-core — a materially larger domain set than the previous version of this section catalogued. One upstream import (imports.gascity) is present and SHA-pinned to github.com/gascityhall/gascity-packs//gascity — confirms Bluefly already follows the upstream SHA-pin pattern for imports, not registry-handle pinning. drupal/recipes/pack.toml also exists (schema 2, name = "recipes") but its only two imports (core, bd) are upstream Gas City internal bootstrap packs, GitHub-SHA-pinned — it does not reference recipe_blucity anywhere. amcs/skills/amcs-drupal-rig/SKILL.md exists and its content (drush-only mutations, read-only by default for patrol formulas, "Drupal is system of record," contrib owns eca/content_moderation/ai_agents/tool/mcp_server) is essentially the operational contract §23 formalizes. amcs/docs/AMCS-MODEL.md exists and independently states the same layer split proposed here — Drupal = content SoR, Gas City = orchestration plane, Gas City = operational runtime on Oracle, Beads+Dolt = work/durable storage — which upgrades the prior version's "AMCS's existing skill philosophy... reportedly says" to RETRIEVED. amcs/docs/DRUPAL-AUTHORITY-MAP.md exists and gives a real per-agent Drupal-ownership table (node, media, taxonomy, content_moderation, workflows, ai_agents, eca, Layout Builder, Migrate API, Search API, cron/Queue API) — this is the concrete, sourced evidence behind the ownership table in §23.2, not an unverified assertion. The Bluefly-side Gas City pack tree. Confirmed real and richer than previously catalogued; internally already consistent with the layer-separation concept below, just not yet wired to recipe_blucity.
blueflyio/agent-platform/ddev-addons/ddev-gascity RETRIEVED: real, main branch. The entire command surface is one bash script (commands/host/gascity, 86 lines, read in full) with a case statement — not separate per-command files. Verified routing: status\|agents\|convoy-list\|rig-list\|doctor → exec blu gascity "$@"; ready\|list\|show\|claim\|create\|close\|done\|update → exec blu beads "$@"; anything else falls through to blu gascity "$@". A generic doctor verb already exists — it is not Drupal/recipe-aware, but it means "ddev gascity doctor" (§23) is a specialization of an existing verb, not a brand-new one. Env-var export block matches exactly: DDEV_PROJECT_NAME, DDEV_PROJECT_TYPE, DDEV_PROJECT_ROOT, DDEV_GIT_BRANCH, DDEV_GIT_COMMIT, DDEV_GIT_REMOTE — no Drupal-version, site-UUID, or installed-recipe detection exists anywhere in the script. bluefly.addon.yaml confirms supports: [drupal-site, drupal-distribution, drupal-contrib, drupal-theme, drupal-profile] and, load-bearing for §23.3, ownership.state: KEEP_THIN with the note "Thin adapter only. Does not run local Gas City supervisor, Dolt server, Town store, or Beads DB inside container." No enroll or recipe verb exists. The local dev-loop bridge inside a DDEV Drupal project. Confirmed thin-adapter-only by its own declared ownership metadata, not just by convention.

Upstream registry role (registry.gascity.com): per upstream Gas City docs (UNKNOWN — not independently re-fetched this session; carried forward from the prior session's research, not re-verified live), a public catalog of reusable, generic factory packs, each identified by a pack.toml + deterministic manifest hash (sorted file path + mode + blob SHA-256). Per the platform's own upstream-first doctrine ([[reference_gascity_canonical_standard_2026-08-20]]), Bluefly's own domain packs in blucity-packs stay Bluefly-private in the GitLab Package Registry; the public upstream registry is for importing generic third-party packs, not for publishing Bluefly's customer-specific Drupal packs. See §23.8 for the GitHub-vs-GitLab conflict finding.

MVP canary re-verified — site_template_amcs (RETRIEVED, current): blueflyio/amcs/site_template_amcs (project id 83310599, main branch, last activity 2026-09-03 — today) is real and active. Its composer.json requires blueflyio/recipe_blucity: dev-release/v0.1.x and blueflyio/recipe_amcs: dev-release/v0.1.x as recipes, confirming the intended composition. It does not reference drupal/agentic_canvas (NOT_FOUND in this composer.json — only drupal/gin, drupal/gin_toolbar, drupal/devel, drush/drush appear beyond the two recipes). Critically: because recipe_blucity is empty (above), this composition is declared but not functional — installing site_template_amcs today cannot resolve real content from its primary foundation recipe. This is the single most concrete, sourced blocker in the whole concept, and it is why the MVP proof in §23.6 must start by making recipe_blucity minimally real before anything else.

The actual gap (why this doesn't already work): recipe_blucity has no content and no pack manifest declaring it as a dependency inside blucity-packs, and ddev-gascity's command surface has no recipe or enroll verb. Closing it is additive, not a new subsystem — matches the platform's own net-negative-LOC and thin-adapter doctrine. See §23 for the full contract, maturity model, and narrowed MVP scope; the original three-step sketch here is superseded by §23.6.

Sources for this section: Gas City Pack Specification (source 15 above); gascity-packs manifest-hash model (https://github.com/gascityhall/gascity-packs) — UNKNOWN, external, not re-verified this session; live GitLab state of the four named repos (recipe_blucity, blucity-packs, ddev-gascity, site_template_amcs), RETRIEVED 2026-09-03.

23. BluCity Drupal Rig Contract (extended concept), 2026-09-03

Extends §22 with the fuller architecture concept the operator drafted from Gas City's public documentation, upstream pack specification, and the same three (now four) Bluefly repos. External claims about docs.gascity.com / registry.gascity.com / github.com/gascity are attributed as upstream source material, not asserted as Bluefly fact — they are UNKNOWN unless separately tagged RETRIEVED above.

23.1 Layer separation

Registry (discovery, not authority) → Bluefly Gas City / Oracle (root pack: foundation/*, platform/*, drupal/*, amcs/* — agents → formulas → beads → sessions → receipts; Beads/Dolt = work authority) → Gas City Rig → Drupal project (Git repo + Composer + .ddev/ with ddev-gascity + Drupal 11 = Drupal state authority). pack.toml = reusable behavior; city.toml = this deployment's bindings; .gc/ = machine-local runtime state. This three-way split is RETRIEVED as Bluefly's actual current practice, not merely proposed — both pack.toml files read in §22 already separate reusable behavior (the pack) from what a specific city imports.

23.2 Ownership table

Concern Owner
Drupal modules installed recipe_blucity / domain recipe
Configuration, content types/entities, moderation/workflow, permissions, AI-provider config, Tool/MCP exposure Drupal (RETRIEVED: DRUPAL-AUTHORITY-MAP.md already assigns content_moderation, workflows, ai_agents, eca this way per-agent)
DDEV runtime DDEV
Project ↔ Gas City transport ddev-gascity
Agent definition + prompt blucity-packs
Multi-step work Gas City Formula
Recurring inspection Gas City Order
Job/work status Beads
Execution history Beads / Gas City receipts
Content/business result Drupal
Source/release GitLab

Avoid the trap of the same process being represented simultaneously as a Drupal workflow and a Gas City formula and an ECA workflow and a CI job and a shell script — pick one owner per concern.

23.3 The BluCity Drupal Rig Contract — a capability contract, not an API

recipe_blucity should not be read as "just a Drupal recipe." It is the Drupal-side portion of a larger contract — the full contract is the union of:

  1. Application profile — recipe_blucity (Drupal capabilities: core version, governance modules, Tool/MCP surfaces).
  2. Project context — GitLab/Git identity (repo path, branch, commit, remote).
  3. Local execution profile — DDEV + Drush (how the rig is actually run and inspected).
  4. Orchestration binding — the Gas City rig + pack pinning (how the central city recognizes and schedules against this project).

No single file today declares all four together — this is a genuine gap (NOT_FOUND anywhere in the three code repos), and it is a documentation/config concept, not a network API: a pack should be able to declare "I require the BluCity Drupal Rig Contract" the same way upstream requires_gc metadata declares a Gas City version floor. Per upstream Gas City docs (UNKNOWN, not re-verified this session), requires_gc is metadata today, not an enforced compatibility gate — so this contract should be validated through doctor/formula checks, not claimed as an enforced dependency mechanism that doesn't exist upstream either.

BluCity Drupal Rig Contract v0.1 (MVP fields — proposed, not yet implemented anywhere):

IDENTITY:
  gitlab_project        # canonical repo path
  branch / commit_sha
  dirty_clean_state

APPLICATION:
  drupal_version         # >=11.4
  site_uuid
  foundation_recipe      # recipe_blucity, pinned version — once it exists
  installed_recipes[]

BLUEFLY FOUNDATION:
  ddev_gascity_version
  supports_capability[]  # e.g. drupal-site, drupal-distribution

CAPABILITIES:
  governance             # content_moderation + workflows present?
  secrets                # key module present?
  tool_api / mcp_server  # present, and enabled?
  ai_agents              # present, and configured?

AUTHORITY:
  drupal_owns[]           # content, config, moderation
  gas_city_owns[]         # scheduling, routing, observation
  beads_owns[]            # work state

SAFETY:
  read_only_default = true
  mutation_requires_bead_authorization = true

RESULT:
  evidence_pointer        # GitLab / Drupal / bead reference

This is deliberately small. It is not a wire protocol; it is the shape of what ddev gascity doctor (or its future recipe/enroll specialization) should be able to assert about a Drupal rig, and what a Gas City pack should be able to declare it needs.

23.4 Drupal Rig Maturity model (R0–R7)

Level Name Meaning
R0 UNMANAGED Plain Drupal project, no Gas City awareness at all.
R1 IDENTIFIED ddev-gascity installed; project identity (name/branch/commit) exportable.
R2 CONNECTED blu CLI reachable from the DDEV container; commands round-trip to Oracle.
R3 REGISTERED Central Gas City knows this project as a rig.
R4 CONTRACTED Rig Contract fields (§23.3) are collected and asserted, at least partially.
R5 OPERABLE_READ A drupal/core-class pack is bound; at least one read-only formula/doctor check runs and returns evidence into Beads.
R6 OPERABLE_WRITE An authorized, bead-gated mutation (e.g. drush recipe:apply, config change) executes and is recorded.
R7 COMPOSED Multiple domain packs (drupal/ai, drupal/accessibility, industry/*) compose on the same rig with declared, checked capability dependencies.

MVP target for this concept is R5 (OPERABLE_READ). R6 (authorized write) and R7 (composed packs) are explicitly deferred to later phases — building toward them now would violate the platform's own vertical-proof-first sequencing.

23.5 Capability status — BUILT / BUILT-PARTIAL / MISSING / NOT_PROVEN (re-verified 2026-09-03)

Capability Status Evidence
Central Gas City model (six primitives, supervisor/orchestrator) NOT_PROVEN this session Not re-queried against Oracle runtime in this session; treated per Part I of this doc as an established upstream fact, not re-derived here.
ddev-gascity command surface (status/agents/convoy-list/rig-list/doctor → gascity; ready/list/show/claim/create/close/done/update → beads) BUILT RETRIEVED — full 86-line script read, case-statement routing confirmed.
ddev-gascity: recipe or enroll verb MISSING RETRIEVED absence — no such case branch; falls through to the default blu gascity "$@".
ddev-gascity: Drupal-specific context injection (Drupal version, site UUID, installed recipes, dirty/clean state) MISSING RETRIEVED — the script only captures DDEV project name/type/root + git branch/commit/remote; no Drupal-aware logic present anywhere in it.
ddev-gascity ownership stance (KEEP_THIN, no local orchestration) BUILT RETRIEVED bluefly.addon.yaml — ownership.state: KEEP_THIN, explicit "does not run local Gas City supervisor, Dolt server, Town store, or Beads DB."
recipe_blucity (Drupal recipe artifact) MISSING RETRIEVED — real repo, one init commit, zero files.
blucity-packs Drupal domain layout (drupal/{core,ai,content,accessibility,migration,search,seo,workflows,recipes}) BUILT RETRIEVED tree + both pack.toml files read in full.
AMCS pack (agents/formulas/orders/skills/docs/mcp/receipts + SKILL.md + AMCS-MODEL.md + DRUPAL-AUTHORITY-MAP.md) BUILT RETRIEVED — all four documents read; content matches the layer-separation and ownership claims in this section.
Formal "BluCity Drupal Rig Contract" spec MISSING RETRIEVED absence — no such file anywhere across the four repos checked; §23.3 is the first attempt to formalize it.
blu rig enroll as a central operation NOT_PROVEN blu-CLI source itself is out of scope for the repos named in this task; confirmed only that ddev-gascity does not expose it (MISSING there specifically).
Pack-compatibility-from-capabilities (requires_gc-style enforcement) MISSING (and UNKNOWN upstream) Per upstream Gas City docs (not re-verified this session), requires_gc is metadata only today, not an enforced gate — so even upstream this is not a real mechanism yet.
End-to-end Drupal rig proof (enroll → pack apply → doctor → bead → formula → evidence → close) NOT_PROVEN No bead/evidence trail found in any of the four repos; Oracle/Beads state was not queried this session.
site_template_amcs as MVP canary BUILT-PARTIAL RETRIEVED — real, active project (last activity today), composer.json correctly declares the recipe_blucity + recipe_amcs composition, but the recipe_blucity half of that composition is empty, so the declared build is currently non-functional.
Public registry (registry.gascity.com) catalog/publish flow UNKNOWN, external Per upstream Gas City docs and the operator's prior research (0 packs / 404 catalog at time of that research) — not independently re-verified this session; treat as unconfirmed-current, not as a current fact either way.

23.6 What to build for MVP (exactly 5 items, R5 target)

  1. BluCity Drupal Rig Contract v0.1 (§23.3) adopted as architecture authority — a doc/config concept, not code.
  2. blu rig enroll as the central operation. This belongs in blu-CLI / the central Gas City side, not in the DDEV adapter — ddev-gascity only ever calls it, per its own KEEP_THIN ownership stance (RETRIEVED, §22).
  3. Minimal ddev-gascity context-collection extension: Drupal version, site UUID, foundation-recipe/package evidence, dirty/clean repo state only. No new orchestration logic, no local Dolt/Beads — an additive read of local state, same shape as the existing git-metadata block in commands/host/gascity.
  4. One drupal/core doctor + one read-only operator/formula: config drift via drush config:status (read-only, matches the existing amcs/skills/amcs-drupal-rig/SKILL.md contract verbatim).
  5. Receipt back into Beads: source SHA, rig identity, capability used, result, evidence pointer — nothing more.

Explicitly NOT in MVP (all Phase 2+): public registry integration, private registry, pack marketplace, capability auto-selection, vertical packs (government, higher-ed, association, etc.), AI agents operating inside Drupal, MCP/Tool API exposure (unless the read-only proof specifically needs it), any mutation flow, a dynamic policy engine, a Drupal-side Gas City UI, a second orchestration system, local Beads/Dolt, or a customer-onboarding abstraction.

23.7 MVP 0.1 proof: Drupal Rig Read-Only Proof

Replaces the longer 15-step lifecycle sketch from the operator's original draft with the narrower MVP sequence:

  1. ddev gascity enroll (once built) triggers blu rig enroll.
  2. Central Gas City recognizes the project as a rig.
  3. The Drupal Rig Contract doctor check passes (minimal fields from §23.3).
  4. drupal/core pack is bound to the rig.
  5. One Bead is created: drupal.config-audit.
  6. ddev drush config:status runs — read-only.
  7. Evidence is returned to the bead.
  8. The bead closes.

No Drupal mutation occurs anywhere in this sequence. R6 (authorized write) and R7 (composed packs) are deliberately out of scope until this proof is clean.

23.8 GitHub-vs-GitLab registry conflict (external, attributed)

Per upstream Gas City docs (UNKNOWN — not independently re-verified this session), the public registry.gascity.com publish flow is designed around a public GitHub repository, registry pack names scoped as <github-owner>/<pack>, and GitHub App ownership verification or GitHub Actions OIDC for strong repository-proof (manual/personal-token submissions are claim-level proof only). That directly conflicts with Bluefly's own binding architecture (GitLab = source/release authority; no GitHub mirror as operational source of truth, per this workspace's SSH-remote/GitLab-authority doctrine). Do not move blucity-packs to GitHub to appear in the public registry — that would invert Bluefly's authority model for a catalog listing. Per upstream Gas City docs (same UNKNOWN caveat), registry commands manage local discovery state while pack imports manage shared city state — when a registry entry is selected, Gas City writes the durable source into pack.toml, not the local registry handle. Bluefly's own already-verified pack.toml files (§22) confirm this pattern is already how Bluefly imports upstream packs (SHA-pinned source =, not a registry handle). Registry.gascity.com should therefore remain upstream discovery only; Bluefly's own packs keep resolving from canonical GitLab sources.

23.9 Two kinds of agents

Drupal-hosted agents (Drupal AI / OSSA) operate inside Drupal's own semantics — content, entities, fields, permissions, tools, moderation, editorial assistance. Gas City agents operating on Drupal are appropriate for cross-repository engineering, migration campaigns, fleet audits, upgrade campaigns, and other long-lived operational work that spans multiple rigs. These are not competing choices — a Gas City formula can invoke a Drupal-hosted Tool/Agent when that is the correct authority (Gas City Agent → Formula → Drupal Tool API/MCP → Drupal Agent/service), and amcs/docs/DRUPAL-AUTHORITY-MAP.md (RETRIEVED, §22) already encodes this split per-agent for the AMCS pack specifically.

23.10 Closing framing

BluCity Drupal Rigs make Drupal projects first-class participants in the central Gas City execution plane — capabilities derived from Drupal recipes and packs, not hand-written agent configuration. A standardized Rig Contract allows Gas City to discover what a Drupal project can safely do and bind reusable agents and formulas to those capabilities. MVP succeeds when one real Drupal rig proves enroll → contract → drupal/core pack → one read-only formula → evidence in Beads, end to end, without creating a second state authority.

Sources for this section: Gas City Pack Specification (source 15 above) and gascity-packs manifest-hash model (https://github.com/gascityhall/gascity-packs) — both UNKNOWN, external, not re-verified this session; live GitLab state of recipe_blucity, blucity-packs, ddev-gascity, and site_template_amcs, RETRIEVED 2026-09-03.