THE GOVERNED PRODUCT FACTORY¶
Gas City, Gas City, and Modern Drupal CMS
Deep technical research, operating model, remote deployment architecture, productization strategy, and market thesis
Curation 2026-09-09 — historical research (22 July 2026), not the current Gas City object model. Current authority: docs.gascity.com and factory-operating-contract.md. Six primitives only: Agent, Bead, Formula, Rig, Pack, Event. The "primitive-by-primitive" table below mixed City, Session, Molecule, Wisp, Convoy, Mail, Order, Sling, and Supervisor into that list. They are mechanisms or pack configuration. Do not cite this report as the primitive list.
Research posture — This report does not treat Bluefly as a greenfield adopter. It incorporates prior decisions and operating contracts: Gas City/Gas City are the execution foundation; Git/GitLab own source and delivery; Oracle owns runtime; the NAS is durable canonical storage; Drupal is a product and governance surface; custom code must justify its lifetime ownership cost.
Prepared for Bluefly.io, LLC Thomas Scola 22 July 2026
Executive Thesis¶
Gas City and Gas City represent an emerging production system for converting durable work state into continuously reconciled engineering output. The product focus shifts from building features to proving the "Modernization Lane." The factory is validated only when a single legacy service is successfully converted, modernized, and decommissioned, with full compliance evidence generated. This MVP is not a software release, but a verified modernization molecule that demonstrates the entire end-to-end lifecycle.
The strategic wedge for Bluefly resides in high-trust regulated services, specifically within the U.S. public sector. Monetization moves away from selling "AI automation" toward selling "governed service modernization." By addressing the Regulated Modernization Gap, Bluefly provides continuous compliance, policy-to-product transitions, and managed technical debt reduction.
Core recommendation — Use the original Gas City pack as the default operating topology until a narrower topology is proven. Productize stable behavior as Gas City packs; productize Drupal capability as recipes/site templates; keep customer-specific differences in configuration, content models, policy, and adapters. Every custom line must cross an explicit ownership threshold.
The Macroeconomic Imperative: The Flat Curve Society¶
The strategic shift toward this factory model is a response to the "Flat Curve Society"—a theoretical framework articulating the structural limitations of model accessibility and the biological limits of human verification. The Bluefly architecture is designed to extract deterministic value from "commodity intelligence" by emphasizing systemic orchestration over raw model power.
The Bluefly Agent Factory abandons the pursuit of single-model supremacy in favor of multi-agent orchestration, heavily structured routing, and deterministic result automation. The intelligence resides in the factory's assembly line, not just in the individual robotic worker. Analysis of developer engagement corroborates this shift; telemetry indicates usage cohorts evolving from zero daily token usage → synchronous single-agent assistance (4M tokens/day) → fully asynchronous multi-agent deployments (12–15M tokens/day).
The Discernment Horizon and Crystallized Knowledge¶
The architecture addresses the "Discernment Horizon"—the boundary beyond which a human operator can no longer safely audit or verify automated output. Gas City utilizes rigorous supervisor planes and policy gates to ensure every output remains inspectable and governed.
The most defensible Bluefly product is a governed digital-service factory for regulated and mission-driven organizations. Gas City operates the engineering factory; GitLab remains the chain of custody; Drupal provides the durable content, workflow, authorization, evidence, and customer-facing product plane.
What Prior Bluefly Work Already Establishes¶
| Established decision | Implication |
|---|---|
| Gas City/Gas City are foundational execution platforms | No parallel scheduler, orchestration bus, or substitute work-state system. |
| Oracle owns runtime | Authoritative supervisor, city state, Beads/Dolt, and long-running agents belong on Oracle. |
| Git and GitLab own source and product delivery | Every change: Repository → Commit → Branch → MR → CI → Merge → Release → Deployment. |
| NAS is canonical durable storage; Mac is disposable | Workstations hold replaceable worktrees, not unique runtime truth. |
| Drupal is the governed product/control surface | Content, workflow, authorization, evidence, and reusable industry capabilities—not a second orchestrator. |
| Contrib-first and net-negative coding | Recipes, modules, ECA models, Canvas components, policies, and adapters precede bespoke modules. |
| Bluefly owns authorization and business contracts | Capability, policy, and product authorization remain Bluefly's differentiating layer. |
| OSSA/DUADP/ContractPlane/ContextControl remain separable | Drupal is a product surface; the standards and evidence model are not Drupal-dependent. |
Part I — Gas City and Gas City¶
1. Light and Dark Factories¶
Gas City: The Declarative Supervisor Plane ("Light Factory") Gas City is the foundational orchestration-builder SDK. It provides a deeply configurable toolkit: runtime providers, work routing logic, processing formulas, structured operational orders, continuous health patrols, and the overarching declarative topological structure of the city itself. Human operators ("Shepherds") deploy, configure, and continuously monitor multi-agent workflows.
Gas City: The Autonomous Runtime Environment ("Dark Factory") Gas City is the specific, highly opinionated implementation and runtime execution environment where multi-agent teams operate entirely autonomously. Agents are deployed with persistent, named roles with rigidly fixed functional responsibilities. An operational outcome is only accepted and merged when consensus is reached mathematically among the adversarial crew. Communication and state persistence between agent roles are managed through Git-backed issue tracking structures ("beads").
1.5. Evolution from NPM to OSSA¶
The legacy @bluefly/agent-forge and @bluefly/tddai NPM packages have been formally deprecated. In their place: the Open Standard Agents (OSSA) protocol. This moves from managing agents as compiled software dependencies to managing them as standardized, interoperable services.
| System | Best description | Use it when |
|---|---|---|
| Beads + Dolt | Durable, queryable, branchable work and coordination substrate | Work must survive sessions, be routed among agents, and remain auditable. |
| Gas City | Opinionated reference factory with named roles and established operating loops | You need a working topology and do not yet have evidence for a custom one. |
| Gas City | Supervisor and SDK for constructing agent factories from declarative primitives | You need reusable topologies, multiple providers, productized packs, or remote/heterogeneous execution. |
| Wasteland | Federation and shared-work concept across many towns | External work exchange, trust, and federated contribution are actually required. |
2. The Architecture by Layer and Plane¶
| Plane | Responsibility | Canonical primitives | Bluefly boundary |
|---|---|---|---|
| Authority plane | Who may define, approve, dispatch, merge, release, and deploy | Human operator, policy, capability, identity, role, gate | Bluefly authorization + GitLab protections |
| Product plane | What durable product and customer capability exists | Product, repository, release, deployment, Drupal recipe/template | Bluefly business object graph |
| Work plane | What work exists and its dependencies/state | Bead, formula, molecule, wisp, convoy, mail, wait | Beads/Dolt; no duplicate task ledger |
| Orchestration plane | How work is routed and coordinated | City, rig, pack, role, agent, order, sling, hook | Gas City; original Gas City pack by default |
| Execution plane | Where an agent process runs and what it can touch | Session, provider, sandbox, worktree, runtime | Oracle-first; workstation as client/optional provider |
| Reconciliation plane | How desired and observed state converge | Supervisor, patrol, health check, wake/sleep, bounded convergence | Gas City/systemd; no wrapper loops |
| Delivery plane | How changes become accepted product | Commit, branch, MR, CI, merge, release, deployment receipt | GitLab pipeline and protected promotion |
| Evidence plane | How claims become inspectable proof | Logs, beads, MR, CI result, runtime receipt, Drupal audit entities | ContractPlane/ContextControl projection |
Zero-Trust Hardware and Network Topology¶
The live, production infrastructure operates on a highly isolated Oracle 3-VM setup.
- bluefly-platform-1: VM.Standard.A1.Flex — 4 OCPUs, 24GB RAM — AD-3, FD-1 — Tailscale 100.64.56.113
- bluefly-origin-restored: Sync Node — Tailscale 100.111.228.30
All connectivity via Tailscale overlay + Cloudflare Tunnels. Secrets managed via 1Password SDK. IaC via Terraform + GitLab CI/CD pipelines exclusively.
7. Primitive-by-Primitive Technical Model¶
| Primitive | Meaning and design intent |
|---|---|
| City | Declarative orchestration environment rooted by city.toml. Composes packs, providers, rigs, agents, policies, and overrides into desired state. |
| Rig | Registered project/repository scope. Binds orchestration to a codebase; allows per-project overrides and workers. |
| Pack | Reusable declarative bundle of roles, prompts, skills, hooks, agents, orders, providers, and topology. Gas City is supplied as a pack. |
| Agent / role | Agent = running or addressable worker identity; role = responsibilities, instructions, tools, and lifecycle. |
| Session | Runtime incarnation of an agent. Sessions may sleep, wake, attach, fail, and be reconciled. |
| Runtime provider | Backend that actually runs sessions (tmux, subprocess, exec, ACP, Kubernetes, hybrid, herdr). |
| Bead | Durable unit of work/state. Carries dependencies, ownership, status, discussion, and routing metadata. |
| Formula | Reusable declarative work pattern. Instantiates larger work structures without manually recreating every task. |
| Molecule | Structured instantiated workflow composed from work atoms/steps; useful for repeatable multi-step delivery. |
| Wisp | Ephemeral or generated work execution pattern for large, formulaic task graphs; lighter lifecycle than product backlog. |
| Convoy | Coordinated group of work items and agents organized around an outcome. |
| Agent-to-agent or operator-to-agent communication persisted in the work substrate. | |
| Wait | Durable dependency on time, condition, gate, or external event—not an agent idling and burning tokens. |
| Order | Declarative or periodic dispatch instruction scanned by the supervisor. |
| Sling | Routing/dispatch action that assigns work into an execution context. |
| Patrol / health check | Recurring operational inspection detecting drift, stalled work, dead sessions, unmet invariants. |
| Gate | Condition that must pass before convergence or delivery advances (CI, approval, policy, runtime proof). |
| Hook | Lifecycle integration attached to events (session startup, work claim, completion, handoff). |
| Skill | Reusable operational instruction/tool contract materialized into an agent context. |
| Prompt | Role-specific operating instruction. In a pack it is versioned product behavior, not an ad hoc chat message. |
| Override / patch | Controlled composition mechanism for adapting a pack without forking the upstream topology. |
| Supervisor | Long-running control loop that reconciles declared city state to sessions and operational reality. |
| Convergence loop | Bounded iterative refinement with gates; terminates on a verified state or explicit blocker. |
8. Infrastructure Layer & Ecosystem Standards¶
| Standard / Component | Definition |
|---|---|
| OSSA | Open Standard Agents protocol; universal transport for agent-to-system and agent-to-agent communication. |
| DUADP | Deterministic Universal Agent Deployment Pattern; ensures every agent instantiation follows a repeatable, auditable lifecycle. |
| ContractPlane | Authoritative projection of all engineering claims into inspectable proof. |
| Agent Blu | Unified identity and capability profile for Bluefly agents. |
| ContextControl | Mechanism for managing agent visibility; prevents context pollution. |
| Upstream | What it contributes | Adoption caution |
|---|---|---|
| Git | Source history, worktrees, isolation, rollback, merge semantics | Worktrees are execution sandboxes, not substitutes for branches/MRs. |
| GitLab (Bluefly) | Repository, MR, CI, release, deployment, authorization integration | Map gates to GitLab without forking core unnecessarily. |
| Beads (bd) | Durable work, mail, formulas, waits, and routing API | Use one authoritative store; avoid shadow task databases. |
| Dolt | SQL database with Git-like branch/merge semantics used by Beads | Monitor version compatibility and backup behavior. |
| tmux | Default and fallback interactive session backend | Useful for operator attachment, but not the architectural control plane. |
| systemd | Host-level lifecycle for the Gas City supervisor on Oracle | One supported service/timer path; no competing wrapper daemons. |
| Packs repository | Reusable topologies and behavior bundles | Promote only stable, smallest-owner behavior; keep machine state out of pack source. |
5. The Gas City Reference Roles¶
| Role | Primary responsibility | Failure it prevents |
|---|---|---|
| Mayor | Human-facing coordinator; decomposes objectives, creates convoys, delegates, and monitors outcomes | Operator manually juggling every agent and losing global intent |
| Deacon | Town-level operational caretaker and health/recovery role | Silent decay, abandoned sessions, and neglected system maintenance |
| Dogs | Lightweight patrol/watchdog processes | Stalls or drift remaining invisible until humans notice |
| Polecats | Ephemeral implementation workers operating in isolated worktrees | Long-lived agents accumulating context, state, and merge collisions |
| Witness | Rig-scoped oversight and coordination | Project-local workers diverging from rig goals or becoming orphaned |
| Refinery | Integration and cleanup stage for combining completed work | Completed patches never becoming coherent, mergeable product |
| Crew | Persistent named collaborators for work needing continuity | Forcing every task into disposable workers when durable context matters |
Interpretation rule — Adopt the operational insight behind any folklore, not the folklore as policy. Bluefly's constitutions, authorization model, GitLab chain of custody, and runtime controls remain authoritative.
9. Remote-Server and Multi-Workstation Deployment¶
Centralized durable orchestration with distributed human access—not duplicated towns on every laptop.
| Location | Runs here | Must not become |
|---|---|---|
| Oracle remote server | gc supervisor, city.toml, Gas City pack, registered rigs, Beads/Dolt, tmux/provider sessions, health checks, runtime receipts | An ungoverned shell playground or hand-edited snowflake |
| GitLab | Repos, branches, MRs, CI, packages/releases, deployment promotion, review evidence | A secondary task tracker that conflicts with Beads work state |
| NAS | Canonical mirrors, archives, large assets, backups, curated standards | The active scheduler or hidden runtime authority |
| Developer workstation | IDE, SSH/API client, local worktree when needed, review, testing, explicit local agents/providers | Unique source of runtime truth, credentials, or unpushed work |
| Drupal environments | Product runtime, content/config, ECA workflows, APIs, evidence projections | A replacement for Gas City orchestration or GitLab delivery |
Reference flow: 1. Operator or product system creates/approves a ready Bead tied to a repository and outcome. 2. Gas City supervisor observes durable work state and dispatches through the appropriate pack/role/provider. 3. Agent receives an isolated worktree and exact role/skill/policy context. 4. Agent implements and tests, then commits and pushes a feature branch. 5. GitLab MR and CI become the acceptance and review boundary. 6. Refinery/integration behavior resolves defects or sends work back with evidence. 7. Merge produces a release/deployment action; runtime verification creates a receipt. 8. Drupal or ContractPlane projects the result for product, governance, and customer visibility. 9. Workstation users attach by SSH, API, or client tooling; they do not duplicate the city.
10. Building Gas City Packs as Repeatable Products¶
A pack becomes a product when it has a narrow promise, stable inputs, measurable outputs, compatibility guarantees, upgrade discipline, and an evidence-producing acceptance path. A directory of prompts is not a product.
| Product layer | Required contents |
|---|---|
| Contract | Problem solved, supported inputs, required upstreams, expected artifacts, exit states, and non-goals |
| Topology | Roles, agents, session lifecycles, routing, waits, patrols, and escalation |
| Behavior | Versioned prompts, skills, hooks, formulas, orders, and gates |
| Provider matrix | Supported execution backends and isolation/resource assumptions |
| Integration | GitLab MR/CI/release bindings, Beads schemas, Drupal/API adapters, secrets references |
| Verification | Golden fixtures, integration tests, policy tests, failure injection, acceptance receipts |
| Operations | Health checks, upgrade/migration notes, observability, backup/recovery, cost controls |
| Governance | Maintainer, trust tier, contribution rules, security policy, semantic versioning, deprecation |
| Commercial packaging | Industry outcome, service boundary, support level, deployment pattern, licensing |
Promotion rule — Begin behavior inside the Bluefly city only when necessary. Promote to blucity-packs only after it is stable, reusable across at least two rigs, and owned by the smallest durable maintainer.
11. Gas City Anti-Patterns¶
- Recreating Gas City roles in custom shell scripts instead of composing or overriding the pack.
- Using chat transcripts, Markdown plans, or a separate dashboard as authoritative work state.
- Launching agents before work is ready, scoped, authorized, and connected to a repository.
- Keeping agents alive while waiting rather than recording a durable wait condition.
- Allowing an agent to bypass branch/MR/CI/release chain of custody.
- Treating the remote server and every workstation as peer authorities.
- Forking upstream because names or defaults are inconvenient instead of using packs, patches, providers, and adapters.
- Measuring productivity by agents launched or tokens spent rather than merged, verified product outcomes.
Part II — Modern Drupal CMS¶
12. Drupal CMS in 2026: The New Product Model¶
Drupal CMS 2.0, released January 2026, is built on Drupal core 11.3. It shifts the default builder experience toward Drupal Canvas, reusable components, site templates, and integrated AI tooling. Agencies and professional developers are the builder audience; marketers and content teams are the end users. AI is framed as infrastructure: workflows should become operable by agents.
The 2026 Contrib Pillars¶
| Contrib pillar | Responsibility |
|---|---|
| drupal/ai | Provider abstraction for LLM/embedding providers; the single allowed transport for LLM calls. |
| drupal/ai_agents | Plugin-based agent framework owning execution, task decomposition, and tool-calling loops. |
| drupal/tool | Typed Tool API with JSON Schema input/output; the only sanctioned execution contract. |
| drupal/tool_belt | Pre-built Tool API tools for common Drupal operations; zero custom code for CRUD. |
| drupal/mcp_server | Config-driven MCP server exposing Drupal as an AI-operable system. |
| drupal/modeler_api | Visual modeler framework (BPMN.io) decoupling modeling logic from the visual substrate. |
| drupal/flowdrop | Pipeline and job entities with visual graph editors and human-in-the-loop lifecycle tracking. |
13. Drupal's Modern Capability Layers¶
| Layer | Modern primitive | Purpose |
|---|---|---|
| Foundation | Drupal core 11.x | Entity, field, configuration, plugin, routing, cache, access, queue, API, and extension framework |
| Capability assembly | Recipes + Config Actions + Default Content + Checkpoints | Declaratively install modules and apply configuration/content changes |
| Product template | Site template / project template | Near-complete industry starting point with polished capability and presentation |
| Presentation | Drupal Canvas + component-based theme + Mercury reference library | Visual composition with live preview while preserving structured data |
| Business automation | ECA + Modeler API + BPMN.io | Model event-condition-action workflows without bespoke glue code |
| AI infrastructure | AI Core, AI Agents, provider plugins, AI Dashboard, tools | Provider-neutral agent and generation capabilities |
| Integration | JSON:API, REST, GraphQL/contrib, webhooks, queues | Expose structured product data and events to other systems |
| Governance | Roles, permissions, workflows, content moderation, revisions, audit modules | Make authority and lifecycle explicit and inspectable |
14. Recipes, Templates, and Components¶
| Artifact | Owns | Does not own |
|---|---|---|
| Recipe | Capability dependencies, config actions, content model, permissions, workflows, defaults | Long-term runtime code or a forced update channel |
| Canvas component | Presentation contract, properties, slots, accessibility behavior, design-system mapping | Core business rules or hidden content structure |
| ECA model | Transparent business rule, event response, approval/integration flow | General-purpose remote engineering orchestration |
| Contrib module | Reusable functional code with community maintenance | Customer-specific configuration |
| Custom module | Only the irreducible product gap, adapter, policy enforcement, or novel reusable capability | Convenience wrappers around existing contrib/config |
| Site template | Integrated industry product experience | A forever-forked Drupal distribution |
15. Net-Negative Coding as an Engineering Policy¶
| Decision order | Question | Preferred action |
|---|---|---|
| 1. Core | Can Drupal core satisfy the requirement? | Configure core; contribute fixes upstream. |
| 2. Supported contrib | Does a security-covered module provide the capability? | Adopt it and participate in its issue queue. |
| 3. Recipe/config | Can existing modules be assembled declaratively? | Create a recipe, ECA model, permissions, config actions, or component composition. |
| 4. Adapter | Is the gap an integration boundary? | Write the smallest plugin/adapter with contract tests. |
| 5. Upstream extension | Is the gap broadly useful? | Implement in the relevant contrib project and contribute it. |
| 6. Custom product code | Is the capability differentiating and irreducible? | Own it with an ADR, tests, maintainer, budget, telemetry, and exit plan. |
| 7. Delete | Has upstream made the custom code redundant? | Remove it promptly and migrate configuration/data. |
2026 Build Sequence — Stop at the first layer that solves the problem¶
- Contrib module — Does a module already do this?
- Recipe — Can this be expressed purely as configuration?
- ECA model — Can this be wired with events, conditions, and actions?
- Tool API plugin — Do you need a new typed executable capability? Write a
@Toolplugin. - AI Context scope plugin — Do you need new context scoping?
- Custom service — Last resort. Requires written justification.
Enforcement Rules¶
- Rule A: AI Core owns provider abstraction. All LLM calls must go through the provider service.
- Rule B: Agents own execution. Multi-step reasoning must use
drupal/ai_agents. - Rule C: Tools own the execution contract. Every capability must be a typed
@Toolplugin. - Rule D: MCP owns the protocol. External tool access must use the MCP Server.
- Rule E: ECA owns workflow. Event-driven automation must use ECA models, not custom event subscribers.
- Rule F: Registry is metadata only. Registries describe capabilities; they do not implement them.
- Rule G: MCP gateway is orchestration only. No business logic in the protocol layer.
- Rule H: Namespace is mandatory. Every custom module must use the
bluefly_prefix. - Rule I: Recipes over modules. If config + recipe + ECA suffices, do not write a module.
- Rule J: Delete duplicates. If custom code duplicates contrib, it must be deleted promptly.
16. Becoming a Good Citizen of Each Framework¶
| Gas City / Gas City | Drupal |
|---|---|
| Use the upstream Gas City pack before inventing topology. | Use core and security-covered contrib before custom modules. |
| Contribute general providers, pack features, docs, and tests upstream. | Contribute fixes to the owning module; co-maintain dependencies the product relies on. |
| Keep local policy and customer behavior in overrides/adapters. | Keep customer variation in configuration, recipes, content, and theme tokens. |
| Respect Beads/Dolt and supervisor invariants. | Respect Drupal APIs, configuration management, update hooks, access checks, cacheability, and security advisories. |
| Version packs and publish compatibility/support matrices. | Version recipes/templates/components; document update and migration behavior. |
| Do not market experimental topology as stable product. | Do not ship unsupported dev releases into a product without an explicit risk decision. |
Part III — The Combined Product Architecture¶
17. MVP: The "Modernization Lane" as Product¶
The Bluefly Agent Factory must shift focus from "building features" to "proving the conversion lane." An MVP is defined not as a software release, but as a verified modernization molecule. The factory is validated only when a single legacy service is successfully converted, modernized, and decommissioned, with full compliance evidence generated.
The "Factory Builder" Sequence¶
- Phase 1–2 (Orchestration Foundation): Stabilize the runtime environment (Gas City) and close the delivery loop (GitLab/CI). Success metric: A clean "healthy" signal from
gc doctorand a completed delivery loop without manual state intervention. - Phase 3–4 (Repeatable Productization): Move from project to product by packaging one capability (e.g., an accessibility recipe). Success metric: The recipe is installable, testable, and maintainable outside the development repository.
- Phase 5–6 (Service Conversion): Execute the first bounded, regulated service modernization. Success metric: Customer-visible service converted and decommissioned with full compliance evidence generated.
18. Monetization: High-Trust Regulated Services¶
Bluefly must shift from selling "AI automation" to selling "governed service modernization." The strategic imperative is to avoid the generic "AI site builder" market and instead monetize the Regulated Modernization Gap, specifically in U.S. public sector and regulated industries.
Service Tiers (Outcome-Based):
- Continuous Compliance as a Service: Sell the process of ongoing accessibility and policy adherence. Shift customers from "annual audit" cycles to a "continuously compliant" factory model.
- Policy-to-Product Factory: Monetize the time-to-compliance. Charge for the ability to ingest new regulations/standards and instantly output required content, tests, and evidence-producing workflows.
- Managed Modernization (Disposition-Based): Price modernization based on the removal of legacy technical debt. Value is found in the elimination of old, insecure, high-maintenance systems.
Economic Advantage: Monetize through the Total Cost of Ownership (TCO) reduction. The factory’s "net-negative coding" policy is a direct financial benefit, marketed as a high-margin service agreement rather than low-margin software licensing or hourly dev fees.
19. Minimum-code implementation patterns¶
| **Requirement** | **Low-ownership implementation** |
| Approval workflow | Content Moderation/Workflows + ECA for notifications/integration |
| Industry data model | Recipe applying content/entity/field configuration and default taxonomy |
| Landing pages | Canvas + Mercury-derived accessible components and design tokens |
| Structured AI memory | drupal/ai\_context item bundles + fields + context scope plugins |
| AI editorial assistant | Drupal AI Agents + provider plugin + narrowly scoped tools + human approval |
| Policy enforcement | Drupal access/validation + Bluefly Cedar adapter only where policy must be externalized |
| Multi-site variation | Composable recipes, config overlays/splits where appropriate, theme tokens, pack rig overrides |
| Compliance reporting | Views/reporting over structured evidence entities populated by event adapters |
| Recurring maintenance | Gas City order/patrol producing Beads and GitLab MRs, not a custom cron shell fleet |
| Migration | Migrate API/contrib mappings generated and verified by a Gas City migration pack |
20. Operating metrics that reward the right behavior¶
| **Metric** | **Why it matters** |
| Ready Beads → merged MRs → verified deployments | Measures actual flow through the factory |
| Lead time by molecule type | Shows whether repeatable product lanes are improving |
| Custom code created vs. deleted/avoided | Makes net-negative coding visible |
| Upstream contribution acceptance rate | Measures ecosystem citizenship and reduced future ownership |
| Recipe/pack reuse across customers and rigs | Distinguishes product from project work |
| Human intervention per verified release | Measures orchestration maturity without pretending autonomy is free |
| Defect escape and rollback rate | Prevents speed from masking quality loss |
| Token and compute cost per accepted outcome | Controls the real economics of multi-agent production |
| Evidence completeness | Confirms each claim has source, test, approval, and runtime proof |
| Legacy disposition rate | Ensures modernization removes old cost rather than layering new systems on top |
21. Phased adoption without building another platform¶
| **Phase** | **Goal** | **Exit evidence** |
| 1\. Stabilize upstream runtime | Run supported Gas City on Oracle, register city/rigs, use Gas City pack, restore clean supervisor/service path | gc doctor healthy; one authoritative city; backup/restore tested |
| 2\. Close delivery loop | Ready Bead → claim → worktree → commit → GitLab MR → CI → merge → release → deployment receipt | Multiple completed loops without manual state reconstruction |
| 3\. Productize one Drupal capability | Create one industry recipe/template with minimal adapters and contribution plan | Installable from clean project; tests; upgrade notes; ownership ledger |
| 4\. Create first industry pack | Encode repeatable build/modernization workflow around that Drupal product | Pack works on two rigs; provider matrix; failure tests; evidence output |
| 5\. Pilot regulated service | Modernize a bounded real service with measurable standards and legacy disposition | Customer acceptance, compliance evidence, retirement or migration proof |
| 6\. Scale product family | Reuse packs/recipes across customers and contribute generalized improvements upstream | Reuse economics, support model, semver releases, community standing |
22. Final recommendations¶
- Treat Gas City as the long-term orchestration SDK and Gas City as the default reference pack—not competing products.
- Keep Oracle authoritative and workstations disposable clients; distribute execution only through explicit providers.
- Make GitLab the non-negotiable product chain of custody and adapt upstream GitHub-oriented examples at the integration boundary.
- Define every sellable capability as a paired artifact: Gas City pack + Drupal recipe/template, joined by tests and evidence.
- Target regulated public-service modernization first, where Drupal’s governance strengths and Bluefly’s experience produce a credible wedge.
- Adopt a formal custom-code ownership threshold and publish code avoided/deleted/upstreamed as a product metric.
- Use Drupal AI as agent-operable infrastructure under permissions and workflows; do not market uncontrolled generation as the product.
- Contribute general fixes and capabilities upstream in both ecosystems; keep Bluefly differentiation in policy, contracts, industry models, evidence, and customer outcomes.
- Do not create another dashboard, bus, task store, scheduler, or agent loop. Project existing authoritative state into customer-facing views.
- Prove one complete modernization lane before multiplying packs, products, or topologies.
Source notes and research references¶
[1] Steve Yegge, “Welcome to Gas City,” 1 Jan 2026.
[2] Steve Yegge, “The Future of Coding Agents,” 5 Jan 2026.
[3] Steve Yegge, “Welcome to Gas City,” 24 Apr 2026.
[4] Gas City Hall, Gas City repository and technical README, current through v1.3.5 (14 Jul 2026).
[6] Steve Yegge, “Welcome to the Wasteland: A Thousand Gas Citys,” 4 Mar 2026.
[7] Steve Yegge, “Gas City: from Clown Show to v1.0,” 3 Apr 2026.
[8] Drupal Association, “Drupal CMS 2.0 is here,” 28 Jan 2026.
[9] Drupal CMS Product Strategy v2.0, June 2026.
[10] “Drupal CMS product strategy: version 2.0,” 6 Jul 2026.
[11] Drupal CMS and Starshot FAQ (recipes and architecture).
[12] Drupal Recipes Initiative.
[13] Drupal CMS AI project and recipe.
[14] ECA: Event–Condition–Action project.
[15] Creating recipes and site templates, Drupal documentation, updated 31 Mar 2026.
[16] Federal Website Standards, GSA/TTS.
[17] Digital.gov, Requirements for Delivering a Digital-First Public Experience.
[18] Section508.gov, OMB guidance on strengthening digital accessibility.
[20] optimizershivam/Bluefly-webapp - GitHub, accessed June 27, 2026.
[21] GitHub - DevWebAbhi/Blufly-E-commerce-Clone, accessed June 27, 2026.
[22] refcell/bluefly: One-shot vagrant engine - GitHub, accessed June 27, 2026.
[23] MASTER-BLUEFLY-AGENT-FACTORY-v.1.3.2.md.
[24] blueflyio/openstandardagents - GitHub, accessed June 27, 2026.
[25] Steve Yegge, “The Flat Curve Society,” accessed June 27, 2026.
[26] Steve Yegge – Medium Home, accessed June 27, 2026.
[27] Steve Yegge: The discernment horizon and loop-driven development, accessed June 27, 2026.
[28] $TFCS The Flat Curve Society Market Data, accessed June 27, 2026.
[29] The Flat Curve Society | Hacker News Discussion, accessed June 27, 2026.
[30] @bluefly/agent-forge | npmjs.org, accessed June 27, 2026.
[31] agentic-chat | npmjs.org keywords, accessed June 27, 2026.
[32] GitHub Agentic Workflows technical preview, accessed June 27, 2026.
[33] Factory - Agent-Native Software Development - GitHub, accessed June 27, 2026.
[34] Agent Factory Status | GitHub Agentic Workflows, accessed June 27, 2026.
[35] Welcome to Peli's Agent Factory, accessed June 27, 2026.
[36] panaversity/agentfactory-business-plugins - GitHub, accessed June 27, 2026.
Research cutoff: 1 August 2026. Upstream projects are moving quickly; version-specific implementation should be verified against the installed release and current upstream documentation before execution. The architectural recommendations intentionally preserve Bluefly’s frozen constitutions and previously settled ownership boundaries.¶
Source: Google Doc "Bluefly_Gas_City_Drupal_Product_Factory_Research_2026-07-22" (id 1Y2Nr2k-FGjXhlNEuu8MTtuXCkZqQ-8KYPdHtfdamckA), received from Thomas Scola 22 July 2026. Complete: all sections through §22 and Source notes are present.