Bluefly Digital Factory — Working Reference Architecture and Autonomous Convoy Directive

Status: Operating directive Purpose: Anchor how Bluefly builds, routes, executes, verifies, learns, and reduces ownership. Work tracking: This document does not track work. Beads track work. Initial execution vehicle: Bluefly Factory — Autonomous Vertical Slice

---

1. North Star

Bluefly is building one operating system for a digital factory.

The factory should accept a real requirement, determine where the work belongs, dispatch the correct disposable workers, execute through governed systems, verify the result, record durable state, and continue without Thomas manually telling each agent what to do next.

The target is not "more automation." The target is:

Requirement
    ↓
Product/workflow system
    ↓
Durable work graph
    ↓
Governed execution
    ↓
Source + CI
    ↓
Verification
    ↓
Result returned to product
    ↓
Next work automatically becomes actionable

The factory succeeds when:

Thomas is not the router.
Thomas is not the credential source.
Thomas is not the memory system.
Thomas is not the CI exception handler.
Thomas is not the person who says "go do the next thing."

Human involvement should be reserved for actual human authority: business decisions, irreversible risk, external commitments, publication gates, exceptional security decisions, and explicit approvals.

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

---

2. Core authority model

These boundaries are not suggestions.

Concern	Authority
Runtime operations	Oracle
Source code	GitLab
Engineering work state	Beads / Dolt
Engineering orchestration	Gas City / Gas City primitives
CMS/product/workflow	Drupal
Reusable CI	blueflyio/gitlab_components
Agent identities	blueflyio/agentictools/agents
Reusable agent skills	blueflyio/agentictools/skills
Reusable factory packs/formulas	Existing governed Gas City / blucity-packs mechanisms
Policy / architecture / Engineering Standard	BluCity-Docs Engineering Standard
Implementation documentation	Owning implementation repository
Secrets	1Password
Verification	Witness, read-only
Routing	Mayor, not production author
Product implementation	Appropriate project/rig specialist
Human authority	Explicitly Thomas or another named human owner

Internal documentation already reinforces the distinction between operational truth, projections, and work authority: Oracle runtime owns operational truth, while Beads own actions; the Mayor fact board is a projection rather than the work graph. Internal source: blueflyio/blu/blucity-docs/Engineering-Standard/operating-model/mayor-fact-board.md.

---

3. The operating law: minimize Bluefly ownership

Every bead starts with the same question:

Can Bluefly own less when this is finished?

The default decision order is:

DELETE
   ↓
REUSE EXISTING
   ↓
USE UPSTREAM
   ↓
CONFIGURE
   ↓
COMPOSE EXISTING CAPABILITIES
   ↓
CONTRIBUTE UPSTREAM
   ↓
THIN ADAPTER
   ↓
CUSTOM SYSTEM — only after a proven gap

A convoy must do at least one of two things:

1. produce real value, or
2. reduce ownership

Preferably both.

Success metrics therefore include:

custom code ↓
custom CI ↓
custom auth paths ↓
duplicated skills ↓
duplicated formulas ↓
one-off scripts ↓
manual routing ↓
polling ↓
Bluefly-maintained abstractions ↓
reusable/upstream capability ↑
customer value ↑

Do not congratulate ourselves for creating a framework that replaces ten lines of configuration.

---

3.1 Gas City Native-First Operating Model

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

Gas City explicitly models an agent as five independent, orthogonal axes: - Harness: Which agent CLI (claude, codex, opencode, gemini, cursor, etc.) - Model: Which model is selected for the task - Upstream: Who serves that model (Cloud provider, LiteLLM gateway, or local LM Studio http://blu.tailcf98b3.ts.net:1234) - Transport: How Gas City drives the harness - Runtime: Where the session executes

Those concerns are deliberately independent. Gas City can change the model or upstream without changing the harness, and the runtime is independently selectable (Gas City Docs).

[!IMPORTANT] No Custom Model Routers: Bluefly must not build its own model-routing/configuration layer merely to switch between Claude, Codex, local LM Studio, LiteLLM, Bedrock, or another OpenAI-compatible endpoint. Use native Gas City upstream declarations in city.toml. Secrets remain environment references ($VAR) in city.toml, backed by 1Password runtime process environment (STD-AUTH-001 / AUTHENTICATE_ONCE=YES).

Native Decision Gate

Add this decision gate ahead of the general ownership gate:

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

8-Tier Ownership Hierarchy

1. GAS CITY NATIVE PRIMITIVE
2. GAS CITY FIRST-PARTY PACK
3. OTHER MATURE UPSTREAM
4. BLUEFLY CONFIGURATION
5. BLUEFLY PATCH / OVERLAY
6. BLUEFLY THIN ADAPTER
7. BLUEFLY PACK
8. BLUEFLY CUSTOM SERVICE

The farther down that list we go, the more evidence is required. A Bluefly custom service should be rare.

Three-Layer Architectural Separation (Hard Law)

Gas City components belong to exactly one of three distinct layers (Gas City Docs): - Layer 1 (Portable Team Definition): pack.toml + pack dirs (agents/, commands/, doctor/, formulas/, orders/, template-fragments/, overlay/, assets/) - Layer 2 (City Deployment Choices): city.toml - Layer 3 (Machine-Local State): .gc/ and .beads/ runtime state

[!CAUTION] Hard Law: Never confuse machine-local .gc/ state with portable definitions. Never commit .gc/ runtime state into packs.

Stop Forking Upstream Gas City Behavior

When Bluefly needs to change the behavior of a Gas City agent, patch the imported pack rather than copying/forking it whenever possible (Gas City Docs). Apply Gas City rig-level patches in city.toml for: - polecat pool size - provider - timeouts - environment - prompts - hooks

Keep truly city-specific roles in the root City pack rather than contaminating or forking generic upstream packs.

Polecats as Native Infrastructure

The Gas City pack defines native scope division: - CITY-SCOPED: mayor, deacon, boot, dog - RIG-SCOPED: witness, refinery, polecat

Do not build a Bluefly worker-pool manager. Configure native Polecat pools per rig.

Token costs are managed by scaling Polecat pool sizes and selecting cheap/local providers (e.g., local LM Studio http://blu.tailcf98b3.ts.net:1234) per rig independently.

Machine Automation Contracts (JSON CLI Law)

Any Bluefly automation, dashboard, hook, test or agent invoking gc MUST use:

gc ... --json
# or --json-schema

Callers MUST respect process exit codes before parsing output, and validate fields against --json-schema contracts (Gas City Docs).

SOFTWARE_CALLING_GC:
  MUST:
    - use --json when supported
    - respect process exit code
    - validate expected fields
    - prefer --json-schema contracts
  MUST NOT:
    - grep human tables
    - regex terminal banners
    - parse spacing
    - depend on prose status messages

External Messaging API (extmsg) for Drupal Handshake

Gas City provides a native HTTP external messaging API (Gas City Docs):

POST /v0/extmsg/clients
        ↓
GET /v0/extmsg/.../subscribe (SSE)
        ↓
POST /v0/extmsg/inbound

Before building a custom Drupal-to-Gas-City conversational bridge, evaluate native client interfaces in this exact decision order: 1. Can extmsg solve it? 2. Can existing MCP solve it? 3. Can Tool API + existing Gas City endpoint solve it? 4. Thin adapter. 5. Stop before inventing platform.

Upstream Pack Registry First

Before proposing a new custom Bluefly pack, search the public first-party pack registry (gascity, gascity, cass, discord, github, slack-full) (Gas City Docs). Always pin pack source and version.

---

4. Factory model

There are two modes.

Light Factory

Default.

Use upstream Drupal, contributed modules, standard libraries, existing GitLab components, existing Gas City primitives, existing protocols and upstream agent infrastructure.

This is the preferred operating mode.

Dark Factory

Bluefly builds something because the requirement genuinely cannot be met upstream.

A Dark Factory component must have:

• a documented upstream gap,
• the smallest viable responsibility,
• a clear owner,
• a maintenance cost,
• an exit/replacement strategy,
• a reason it cannot be configuration or a thin adapter.

If those cannot be stated, do not build it.

---

5. Current priorities

The factory effort does not begin with new product architecture.

The current order is:

P0 — Finish Gas City control-plane convergence

Oracle is runtime authority.

The Mac is a source/operator surface, not a second City.

The shared Dolt architecture must become reliable and boring. Existing rig inheritance should be preserved. Missing logical-database provisioning or broken native City/Beads identity should be corrected through native mechanisms rather than building synchronization systems.

No new Dolt authority. No second ledger. No flattening all rigs into a fake single database. No custom sync.

The current internal fact board has recently recorded live Gas City identity/store problems including native_store_unavailable / missing metadata project identity, so agents must inspect live state before assuming this layer is solved. Internal source: blueflyio/blu/blucity-docs/Engineering-Standard/operating-model/mayor-fact-board.md.

P1 — Make Beads the actual durable work graph

No Markdown project plan becomes a substitute ledger.

No chat becomes durable task authority.

No agent memory becomes durable task authority.

A durable work item becomes a bead.

Documents explain why and how. Beads record work and state.

P2 — Finish shared CI convergence

blueflyio/gitlab_components is the reusable CI authority.

Consumer repositories should compose it rather than reimplement it.

When multiple projects fail with the same reusable signature:

owner = gitlab_components

Fix it once.

Do not repair thirty repositories individually because one shared contract is wrong.

P3 — Normalize the Drupal factory

Separate deliberately:

private Bluefly implementation
contrib-ready implementation
Drupal.org/public release

For contrib-ready work:

Composer validates
tests pass
GitLab CI passes
public repo is clean
Drupal.org becomes second gate
human review remains before main/publish

Drupal implementation repos own implementation documentation.

Engineering Standard owns platform policy.

P4 — Prove this against revenue

Infrastructure is not the final deliverable.

Use a real AMCS/customer requirement as the forcing function.

The factory improves by manufacturing something people will actually pay for.

---

6. Team model

Do not create more standing agents unless execution proves a missing role.

Use and improve the team already present.

BLU

Architecture and capability curation.

BLU should:

• orient the convoy,
• inspect existing capabilities before creating anything,
• identify duplication,
• enforce authority boundaries,
• curate agent definitions/skills/formulas,
• reduce Bluefly ownership.

BLU is not a substitute for Beads.

Mayor

Routes.

Mayor should:

inspect work graph
identify ready work
route to appropriate rig/worker
surface true authority blockers
continue routing other work

Mayor does not become the production author.

Witness

Read-only independent verification.

Witness verifies claims and evidence.

Witness does not repair what it is verifying.

Refinery

Curates reusable capability after evidence exists.

Refinery asks:

Did this happen repeatedly?
Is the pattern stable?
Does upstream already solve it?
Should it become:
  component
  skill
  formula
  upstream contribution
  nothing

Do not promote a pattern after one use.

Default threshold: at least two demonstrated uses before promotion unless a standard requires otherwise.

Foundry / Forge / infrastructure specialists

Own build-system, CI, shared infrastructure and execution-layer work according to existing repo authority.

They should prefer shared fixes over consumer patches.

Drupal

Owns Drupal implementation correctness and Drupal architecture ordering.

Preferred delivery order remains:

contrib/upstream
→ config
→ Recipe
→ Canvas/SDC
→ ECA
→ Tool API
→ AI Context / existing integration
→ existing Bluefly module
→ thin custom service only after proven gap

Harbormaster

Runtime/estate custody where assigned.

Sentinel

Security/policy enforcement where assigned.

OpenClaw and other runtime agents

Execution substrate, not new authority.

Rig specialists such as AMCS

Know their product boundary.

They should not reinvent global factory mechanics.

---

7. Canonical agents and skills

Before an agent creates instructions, copies prompts, or writes a local skill, it must inspect:

blueflyio/agentictools/agents
blueflyio/agentictools/skills
blueflyio/blu/blucity-packs
BluCity Engineering Standard

One capability gets one canonical home.

Reference it elsewhere.

Do not copy the same skill into:

agent prompt
project README
Claude/Cursor config
Gas City formula
BluCity Docs
another agent repo

Repetition should trigger consolidation, not another copy.

---

8. Learn before acting

Every standing agent begins a new domain task with an orientation pass.

The sequence is:

1. Read the relevant Engineering Standard.
2. Inspect current Beads.
3. Inspect current authoritative repo state.
4. Inspect upstream documentation when an upstream system is involved.
5. Search existing skills/formulas/components.
6. Determine authority.
7. Execute only then.

Do not assume a six-week-old architecture note describes the current runtime.

Do not trust old chat receipts over live GitLab, live Oracle, or authoritative Beads.

Do not invent an identity, vault reference, endpoint, package, formula, or owner because one is convenient.

---

9. Cost and model policy

Model cost matters, but do not build another model-routing platform to solve it.

Use existing provider abstractions.

Classify work by reasoning need.

Example operating tiers:

LOCAL / CHEAP
- classification
- search summarization
- formatting
- routine code inspection
- simple test repair
- documentation curation
- repetitive transformations

MID
- implementation with bounded context
- code review
- repo-specific debugging

HIGH
- architecture
- ambiguous production incidents
- security reasoning
- cross-estate convergence
- difficult migrations

You already proved that LM Studio is available over the tailnet at:

http://blu.tailcf98b3.ts.net:1234

with OpenAI-compatible /v1 endpoints and multiple local models.

Treat this as a provider, not a new architecture.

Do not move the runtime authority to NAS simply to use local models. NAS remains storage/artifact infrastructure unless another standard explicitly changes that.

Agents may use local/network-accessible models where the task fits their capability, reserving expensive cloud models for work that genuinely benefits from them.

Cost optimization must not lower security or governance.

---

10. Event-driven continuation

Polling should be exceptional.

The factory should use events wherever the upstream system provides them.

In particular:

GitLab webhook
    ↓
Gas City event/order
    ↓
formula/work transition
    ↓
worker

Success and failure both create meaningful state transitions.

Examples:

pipeline succeeded
pipeline failed
MR merged
MR blocked
deployment completed
Drupal workflow event
external approval received

Events should wake the system.

They should not wake Thomas.

No loop such as:

while true:
  check pipeline
  sleep 30

unless no upstream event mechanism exists and the exception is documented.

---

11. Orders, Formulas and Beads

Keep the concepts separate.

Internal Engineering Standard currently describes the relationship as:

Formula = HOW
Order   = WHEN / WHERE / WHICH SCOPE
Beads   = durable work/state

It also documents Formula materialization as durable graph state: a root bead and child step beads rather than orchestration state living only in process memory. Internal source: blueflyio/blu/blucity-docs/Engineering-Standard/catalog/gc-formulas.md.

Therefore:

Event
  ↓
Order
  ↓
Formula
  ↓
materialized Beads
  ↓
workers execute

Do not make a Formula for trivial shell glue.

Do not make a Formula merely because a workflow has two steps.

Use formulas when the workflow is reusable, multi-step, conditional, parallel, approval-sensitive, or valuable enough to persist/replay.

---

12. Self-expanding convoys

Do not predict the entire project graph in advance.

Seed the minimum spine.

Then execution discovers the rest.

A running Formula or worker may create child beads when it encounters:

missing capability
broken authority path
failed CI
missing machine permission
upstream gap
unavailable dependency
unexpected implementation work

This produces an honest graph.

Avoid another 200-item speculative project plan.

The rule is:

Discovered work becomes linked child work. Predicted work does not automatically become bureaucracy.

---

13. Polecats and disposable execution

Polecats are workers.

They are not durable state.

The internal BluTown implementation explicitly encodes this distinction:

"A bead is work. A polecat is an agent."

Internal source: blueflyio/blu/blucity-docs/products/BluTown/dashboard/src/components/operator/AgentStatusPanel.tsx.

The correct lifecycle is:

ready bead
    ↓
Polecat claims
    ↓
executes scoped work
    ↓
produces commit/MR/evidence
    ↓
updates durable state
    ↓
disappears

A Polecat dying must not destroy:

work state
decision history
evidence
next action
authority

That belongs outside the worker.

Do not create a custom worker-pool abstraction on top of Polecats unless upstream cannot satisfy a demonstrated requirement.

---

14. Hooks and automation

Use native hooks before custom orchestration.

Examples:

gc hook
GitLab webhooks
Drupal events
ECA events
MCP calls
Tool API
native CI callbacks

A hook should create or advance governed work.

Do not use hooks to bypass governance.

Bad:

GitLab webhook → random shell script → production mutation

Good:

GitLab webhook
→ identify governed work
→ invoke Order
→ materialize/advance Bead
→ authorized worker executes
→ evidence recorded

---

15. Drupal ↔ Gas City boundary

Do not merge Drupal and Gas City into one architecture.

Drupal owns:

content
CMS configuration
product workflow
editorial/user state
business/product UX
ECA workflow
Drupal permissions

Gas City owns:

engineering work
Beads
Orders
Formulas
worker dispatch
engineering continuation

The handshake should remain thin.

Drupal → Factory

Preferred path:

Drupal action / ECA
        ↓
Tool API
        ↓
governed factory capability

Factory → Drupal

Preferred path:

Gas City
    ↓
MCP / existing governed Drupal tool
    ↓
Drupal operation

Do not build a generic integration platform before one real workflow proves what is missing.

---

16. Documentation discipline

Three layers:

Engineering Standard

Owns:

policy
architecture
authority
standards
decision rules
cross-repository operating law

Implementation repository

Owns:

installation
implementation
API
configuration
developer instructions
tests
runtime specifics

Beads

Own:

work
status
blockers
dependencies
execution evidence
completion

A document references Beads when work derives from it.

Do not turn the document into an ever-growing task checklist.

---

17. Machine identities

This remains P0.

Standing actors with real execution authority require actual identities.

Rules:

least privilege
no borrowing Thomas's identity
no placeholder principal
no guessed service account
no hard-coded credentials
1Password remains secrets authority
authorization and authentication remain distinct

If a machine identity does not exist:

create/route bead
mark dependent mutation work blocked
continue safe independent work

Do not stop the whole factory if documentation, auditing, classification or other read-only work remains available.

---

18. Initial Convoy

Bluefly Factory — Autonomous Vertical Slice

Outcome

One real requirement enters through Drupal, crosses into Gas City only when engineering work is required, executes verifiably using disposable workers and GitLab, persists through Beads/Dolt, returns its result to Drupal, and causes subsequent work to continue without Thomas manually pushing the process forward.

This is not a demo.

Use an AMCS/customer requirement that creates actual value.

---

19. Seven seed beads

Do not pre-create fifty follow-up beads.

Start with these seven.

---

BEAD 1 — Authoritative work scopes

Title

factory: prove authoritative bead scopes for autonomous vertical slice

Goal

Every participating rig can access its proper authoritative work graph.

Required proof

RIG=
BEAD_PREFIX=
AUTHORITY=
DATASTORE=
READ_PROOF=
WRITE_PROOF_IF_AUTHORIZED=
RECOVERY_PATH=NATIVE
NEW_DOLT_SERVER=NO
CUSTOM_SYNC=NO
PACK_LAYER_IDENTIFIED=YES
CITY_DEPLOYMENT_LAYER_IDENTIFIED=YES
LOCAL_BINDINGS_IDENTIFIED=YES
PORTABLE_STATE_IN_.GC=NO
MACHINE_STATE_IN_PACK=NO

Do not repair uncertainty by building another data layer.

Child beads are allowed only for actual discovered defects.

---

BEAD 2 — Standing machine identities

Title

factory: provision least-privilege identities for autonomous actors

Only provision roles actually needed for this convoy.

Acceptance

THOMAS_IDENTITY_BORROWED=NO
PLACEHOLDER_IDENTITY=NO
1PASSWORD_AUTHORITY=PRESERVED
LEAST_PRIVILEGE=YES
SECRET_VALUE_PERSISTED=NO
AGENT_IDENTITY_DISTINCT=YES
GC_CONFIG_DISTINCT=YES
UPSTREAM_CREDENTIAL_DISTINCT=YES
MACHINE_RUNTIME_IDENTITY_DISTINCT=YES

Authorization gaps become child beads. Do not collapse identity, configuration, upstream credentials, and machine runtime identity.

---

BEAD 3 — Native agent & provider convergence

Title

factory: map standing agents onto Gas City five native axes and local upstream

Goal

Map Bluefly's standing agents onto Gas City's five native axes (harness, model, upstream, transport, runtime) rather than inventing parallel configuration layers. Wire local LM Studio (http://blu.tailcf98b3.ts.net:1234) as a native upstream in city.toml.

Schema per Agent

AGENT=
ROLE=
SCOPE=city|rig
HARNESS=
MODEL=
UPSTREAM=
TRANSPORT=
RUNTIME=
PACK_SOURCE=
BLUEFLY_PATCH=
SECRET_REFERENCE=
CAN_USE_LOCAL_MODEL=
WHY_NOT_IF_NO=

Acceptance

CUSTOM_MODEL_ROUTER_CREATED=NO
BUILTIN_HARNESSES_USED=YES
LOCAL_LM_STUDIO_CONFIGURED=YES
UPSTREAM_SECRET_REFS_USED=YES
NO_PLAINTEXT_TOKENS_IN_CITY_TOML=YES

---

BEAD 4 — Polecat real-work proof

Title

factory: execute one real engineering change through disposable Polecat

Use one safe but real AMCS/customer-related engineering change.

Required lifecycle:

Bead
 ↓
Polecat
 ↓
branch
 ↓
implementation
 ↓
tests
 ↓
MR → release/v0.1.x
 ↓
CI
 ↓
evidence
 ↓
worker disposable

Acceptance

WORK_EXISTED_BEFORE_WORKER=YES
WORK_SURVIVES_WORKER=YES
STATE_IN_AGENT_MEMORY=NO
CORRECT_RELEASE_FLOW=YES
CI=PASS
RESULT_RECORDED=YES

No shepherding.

---

BEAD 5 — Thinnest native Drupal / Gas City handshake

Title

factory: prove thinnest native Drupal-to-Gas-City capability boundary

Evaluate and prove the thinnest native handshake using the decision ladder: 1. extmsg (Native External Client API: POST /v0/extmsg/clients, SSE subscribe, POST /v0/extmsg/inbound) 2. MCP Gateway / Servers 3. Tool API + existing Gas City endpoint 4. Thin adapter 5. Stop before inventing platform

Prove one operation each direction.

Drupal → Gas City

Drupal/ECA
→ extmsg or Tool API
→ governed factory action

Gas City → Drupal

Gas City
→ MCP / existing Drupal tool
→ Drupal

Acceptance

CALL_DRUPAL_TO_FACTORY=PASS
CALL_FACTORY_TO_DRUPAL=PASS
SHARED_DATABASE_SHORTCUT=NO
DUPLICATE_WORK_STATE=NO
GENERAL_PLATFORM_CREATED=NO
TRACEABLE_TO_BEAD=YES

If Tool API or MCP is insufficient, create a narrowly scoped child bead describing the exact gap.

---

BEAD 6 — Real AMCS vertical slice

Title

factory: execute production-relevant AMCS requirement end to end

Selection criteria:

REAL
USEFUL
SMALL ENOUGH TO FINISH
REQUIRES PRODUCT + ENGINEERING
WORTH KEEPING

Target lifecycle:

AMCS requirement
      ↓
Drupal workflow
      ↓
Tool API
      ↓
Gas City Order
      ↓
Formula / Beads
      ↓
Polecat
      ↓
GitLab
      ↓
CI
      ↓
GitLab event
      ↓
Gas City continuation
      ↓
Drupal result/state

Acceptance

CUSTOMER_VALUE=YES
THOMAS_ROUTING_STEPS=0
DURABLE_WORK_IN_BEADS=YES
CI=PASS
EVENT_CONTINUATION=PASS
DRUPAL_RESULT_REFLECTED=YES

Internal Formula documentation already uses AMCS as an example of composing a Convoy, Formula, Order and rig, which makes it a natural forcing function. Treat named examples as patterns and verify deployed formulas before assuming they exist. Internal source: blueflyio/blu/blucity-docs/Engineering-Standard/catalog/gc-formulas.md.

---

BEAD 7 — Autonomous continuation and ownership gate

Title

factory: prove autonomous continuation and negative ownership

This is the real test.

After execution begins:

Thomas stops issuing next-step instructions.

Agents must derive the continuation from:

Beads
events
Orders
dependency state
authority

Witness independently verifies.

Every created artifact gets:

KEEP
UPSTREAM
REPLACE_WITH_EXISTING
DELETE

Every repeated pattern gets evaluated for:

existing upstream capability
shared GitLab component
skill
Formula
upstream contribution
nothing

Acceptance

THOMAS_AS_ROUTER=NO
MAYOR_ROUTING=YES
WITNESS_READ_ONLY=YES
WORK_CONTINUES_AFTER_BLOCKER=YES
OWNERSHIP_DELTA<=0
UNJUSTIFIED_NEW_PLATFORM=NO

---

20. Dependency spine

               ┌──────────────┐
               │ 1. Authority │
               └──────┬───────┘
                      ↓
               ┌─────────────┐
               │ 2. Identity │
               └──────┬──────┘
                      ↓
               ┌───────────┐
               │ 3. Events │
               └─────┬─────┘
                    ↙   ↘
        ┌──────────┐   ┌────────────────┐
        │4 Polecat │   │5 Drupal/Factory│
        └────┬─────┘   └───────┬────────┘
             └────────┬─────────┘
                      ↓
               ┌────────────┐
               │  6. AMCS   │
               └─────┬──────┘
                     ↓
               ┌─────────────┐
               │ 7. Autonomy │
               └─────────────┘

---

21. Two-week execution shape

The seven beads remain the work graph. The two-week structure is merely sequencing guidance.

Week 1 — Make the factory capable of acting

Parallel lanes:

Mayor + platform specialists
    → Beads/Dolt/City authority

identity/security owners
    → machine identities

Foundry / CI
    → gitlab_components convergence

BLU + Refinery
    → skills/formulas/component inventory and deduplication

Drupal
    → factory boundary and repo classification

Witness
    → independent proof throughout

By the end of week 1:

authority works
identities required for mutation exist
events can wake the factory
shared CI is reliable
one disposable worker can execute
Drupal handshake is proven

Week 2 — Manufacture something

Execute Beads 6 and 7.

Use real AMCS work.

Do not spend week 2 improving infrastructure because it is interesting.

Infrastructure repair is allowed only when the actual production slice discovers the need.

---

22. Continuous dispatch law

No agent may stop because one dependency is waiting when other authorized work exists.

When blocked:

record evidence
update/create correct bead
route dependency
mark WAITING_ON=<specific thing>
immediately select next ready authorized work

Forbidden terminal responses:

waiting on CI
waiting for review
nothing else to do
let me know
shall I continue
what should I work on next?

If the graph has ready work, work it.

---

23. The learning loop

Execution should continuously make the factory smaller and smarter.

FIRST OCCURRENCE
→ solve narrowly

SECOND OCCURRENCE
→ compare

STABLE REPETITION
→ determine canonical reusable form

Possible destination:
  upstream contribution
  GitLab component
  skill
  Formula
  shared library
  configuration
  deletion of duplicated implementation

Never document the same workaround five times.

Abstract only after evidence.

---

24. Completion test

This convoy is not complete because seven beads are closed.

It is complete when the system proves:

REAL_REQUIREMENT_USED=YES
CUSTOMER_VALUE_PRODUCED=YES

ORACLE_RUNTIME_AUTHORITY=PRESERVED
GITLAB_SOURCE_AUTHORITY=PRESERVED
BEADS_WORK_AUTHORITY=PRESERVED
DRUPAL_PRODUCT_AUTHORITY=PRESERVED

NEW_DOLT_AUTHORITY=NO
NEW_SYNC_LAYER=NO
NEW_AGENT_FRAMEWORK=NO
NEW_EVENT_PLATFORM=NO
NEW_MODEL_ROUTER=NO

MACHINE_IDENTITIES=PROVEN
THOMAS_CREDENTIAL_BORROWING=0

POLECAT_EXECUTION=PROVEN
WORK_SURVIVES_WORKER=YES

GITLAB_EVENT_SUCCESS=PROVEN
GITLAB_EVENT_FAILURE=PROVEN
POLLING_REQUIRED=NO

DRUPAL_TO_FACTORY=PASS
FACTORY_TO_DRUPAL=PASS

CI_SHARED_COMPONENTS_USED=YES
PROJECT_CI_SNOWFLAKE_CREATED=NO

THOMAS_MANUAL_CONTINUATIONS=0

WITNESS_VERIFICATION=PASS

OWNERSHIP_DELTA<=0
VALUE_DELIVERED=YES

Then ask one final question:

Can we now delete anything we needed during the proof?

If yes, delete or retire it through the governed process.

---

25. Bootstrap directive to BLU

This is the actual handoff I would give BLU:

Operate the Bluefly Digital Factory Autonomous Vertical Slice convoy.

Begin by reading the relevant current Engineering Standard, current Beads, canonical agent/skill repositories, and upstream documentation for any technology you touch. Do not use this directive as a substitute for live authority.

Create or reconcile only the seven seed beads defined by the convoy. Do not pre-plan the whole project. Existing matching beads win over duplicates.

Oracle is runtime authority. GitLab is source authority. Beads/Dolt are durable engineering-work authority. Drupal owns product/CMS workflow. gitlab_components owns reusable CI. agentictools/agents owns canonical agent definitions. agentictools/skills owns reusable skills. 1Password owns secrets. Witness verifies read-only. Mayor routes but does not become production author.

Default every decision through delete → reuse → upstream → configure → compose → upstream contribution → thin adapter → custom only on proven gap.

Use existing agents and capabilities before adding new ones. Use Polecats as disposable workers. Work state must survive the worker. Prefer native Gas City Orders, Formulas, hooks and Beads rather than Bluefly orchestration code.

Make continuation event-driven. Use GitLab webhooks and Drupal events rather than polling wherever upstream supports them. Events should resolve governed work and trigger Orders/Bead transitions, not execute uncontrolled production mutations.

Use local/network-accessible models for appropriate low-cost work through existing provider abstractions. Do not create a custom model router and do not change NAS/runtime authority merely to reduce token cost. Reserve expensive models for work whose reasoning difficulty justifies them.

Do not borrow Thomas's credentials. Provision least-privilege machine identities where execution requires them. A missing identity blocks only the mutation requiring it; route the dependency and continue other safe work.

Use AMCS as the real vertical-slice forcing function unless current Beads show a better revenue-bearing customer requirement. This must deliver something worth keeping, not a demonstration invented to prove the factory.

Never ask Thomas what to do next when the work graph, events, dependencies or standards already answer the question. Escalate only genuine human-authority decisions.

When execution discovers missing work, create linked child beads. Do not expand a speculative plan beforehand.

When repetition appears, Refinery determines whether it should become upstream contribution, shared CI component, skill, Formula, library/configuration, or nothing. Do not promote abstractions after one use.

The convoy is successful only when a real requirement goes Drupal → governed factory → disposable worker → GitLab/CI → event continuation → result back to Drupal, durable state remains in Beads, Witness can independently prove the run, Thomas did not manually route intermediate steps, and Bluefly finishes with equal or less long-term ownership than it started with.

That is the version I would treat as the single working directive. It incorporates the control-plane cutover, Beads/Dolt, CI convergence, Drupal factory, team/agent roles, skills and formulas, Polecats, hooks, event-driven continuation, machine identities, model/token cost, AMCS revenue proof, self-expanding Beads, documentation boundaries, and the negative-ownership rule rather than treating them as separate initiatives.