Production Deployment Law & Provenance Standard¶

1. Core Invariant & Authority Rule¶

STOP TREATING ORACLE (OR ANY PRODUCTION RUNTIME) AS A DEVELOPMENT CHECKOUT.

PROHIBITED ON PRODUCTION:
❌ ssh → git pull
❌ ssh → git checkout branch
❌ ssh → edit configuration/source
❌ ssh → docker compose pull / restart
❌ Production-local source mutation

REQUIRED PRODUCTION PATHWAY:
GITLAB (Source Authority: main)
   │
   ▼
CI / TEST (Quality Gate)
   │
   ▼
APPROVED RELEASE / PROMOTION TAG
   │
   ▼
IMMUTABLE ARTIFACT (Locked Container Digest / Release Package)
   │
   ▼
IAC / AGENT-DOCKER (Host & Runtime Projection)
   │
   ▼
ORACLE RUNTIME (Disposable Execution Layer)
   │
   ▼
VERIFICATION (MAYOR / WITNESS Acceptance)

Oracle consumes RELEASED OUTPUT — never developer branches, release/v0.1.x, MR branches, or local checkouts.

2. Allowed Production Inputs¶

Production deployments may be derived ONLY from: 1. main commit (promoted from tested release). 2. An approved, immutable release tag. 3. An immutable GitLab artifact/package in the GitLab Package Registry. 4. An immutable container digest (registry.gitlab.com/...@sha256:<digest>) produced by approved GitLab CI.

Final Runtime Identity:¶

$$\text{Runtime Identity} = \text{TAG} + \text{ARTIFACT VERSION} + \text{CONTAINER DIGEST}$$

Strictly Prohibited Sources:¶

feature/*
release/v0.1.x (Integration branch only; NOT a production source)
MR branches
Developer worktrees
Local workstation checkouts
Oracle-local checkouts
Detached arbitrary commits not represented by a governed release

3. Branch Promotion & Release Sequence¶

DEVELOPMENT:
  feature/* ──► MR ──► release/v0.1.x (Integration & Testing)

PROMOTION:
  release/v0.1.x ──► Promotion MR ──► main (Human Gate / Approval)

PRODUCTION:
  main
   │
   ▼
  GitLab CI Tag & Build
   │
   ├── Container Registry  ──► OCI image @ sha256:<digest>
   ├── Package Registry    ──► Versioned Release Bundle / Binary
   └── Generic Registry    ──► Configuration / Systemd Manifests
   │
   ▼
  IaC / agent-docker Deployment
   │
   ▼
  Oracle Execution Layer
   │
   ▼
  MAYOR & WITNESS Independent Verification

4. Responsibility Boundaries¶

Layer	Repository / Authority	Responsibilities
Orchestration	`BLU` / `Gas City`	Cross-fleet coordination, work tracking (`bd`), priority routing
CI & Release	`REFINERY` / GitLab CI	Building, testing, tagging, publishing immutable packages & digests
Runtime Def	`agent-docker`	Container manifests, locked image digests, healthchecks, systemd projections, volumes, resource limits
Host Infra	`IaC` (Terraform/Cloud-Init)	VM provisioning, network, storage, dependencies, bootstrap, deployment invocation, drift detection
Runtime Obs	`MAYOR`	Oracle production observation, fact board, deploy acceptance
Audit & Proof	`WITNESS`	Independent verification of commit, tag, artifact, and digest provenance

5. Deployment & Rollback Contract¶

Deployment Receipt Requirement:¶

Every production deployment must record:

PROJECT=
SOURCE_COMMIT=
SOURCE_BRANCH=main
SOURCE_TAG=
PIPELINE_ID=
DEPLOY_JOB=
ARTIFACT=
ARTIFACT_VERSION=
ARTIFACT_DIGEST=
CONTAINER_IMAGE=
CONTAINER_DIGEST=
IAC_COMMIT=
AGENT_DOCKER_COMMIT=
TARGET_HOST=
DEPLOYED_AT=
PREVIOUS_VERSION=
NEW_VERSION=
HEALTHCHECK=
FUNCTIONAL_CHECK=
ROLLBACK_ARTIFACT=
DRIFT_AFTER_DEPLOY=0

Rollback Contract:¶

Rollback means selecting the previous known-good immutable artifact/digest and executing a governed deployment. Rollback is NEVER git reset, git checkout, git stash, or manual file manipulation on the production host.

6. Client vs Gateway Architecture (e.g. OpenClaw)¶

Workstations (Mac, iPad, Phone) are clients: $$\text{Mac / iPad / Phone} \longrightarrow \text{wss://claw.copaw.us} \longrightarrow \text{Oracle OpenClaw Gateway} \longrightarrow \text{NAS Workspace}$$

Workstations MUST NOT run local docker exec wrappers or impersonate the Oracle gateway. All client tooling connects through the authorized remote gateway endpoint (OPENCLAW_GATEWAY_URL).

7. Reproducibility Law — Infrastructure and Configuration as Code Are Mandatory¶

Production state may prove what exists, but only source-controlled infrastructure and configuration define what is intended to survive a rebuild.

Bluefly servers are disposable execution surfaces. No server, container, host, VM, mini PC, or workstation MAY be the unique authority for how the system is configured.

If a machine vanished, Bluefly MUST be able to rebuild the host, reinstall the platform, restore secrets by reference, redeploy every service, reattach durable data, and return to the same governed state without reading the old filesystem, using only:

GitLab source
infrastructure as code
deployment definitions
configuration as code
package and version locks
secret references
durable data backups
documented restore procedures

Consequences, binding:

Condition	Classification
Required for operation, exists only on a live machine	`DRIFT`
Would disappear during a clean rebuild	`TECHNICAL_DEBT`
Manually changed on a server, not represented in source	`NOT_DONE` — MUST NOT be reported as complete

7.1 The rebuild test¶

For every service, host, project, and platform component, ask:

If this machine vanished right now, could we provision a replacement and reproduce the same intended state without reading the old filesystem?

If NO, create or update a Bead against the project that owns the missing declaration. Do not collect every finding into one infrastructure Bead — each gap belongs to its owning project (§11).

7.2 Every running service must have a code owner¶

For every running service, establish:

SERVICE=  HOST=  PURPOSE=  PROJECT_OWNER=  SOURCE_REPO=
DEPLOYMENT_DEFINITION=  CONFIGURATION_SOURCE=  VERSION_PIN=
SECRET_REFS=  DATA_VOLUMES=  BACKUP_SOURCE=  RESTORE_PROCEDURE=
HEALTHCHECK_SOURCE=  STARTUP_MECHANISM=  NETWORK_BINDINGS=
DNS=  TLS=  OBSERVABILITY=  RUNTIME_STATE=  REBUILD_VERIFIED=

Any field required to reproduce the service that is unknown yields REPRODUCIBILITY=FAIL and BEAD_REQUIRED=YES.

8. A Live Server Is Evidence, Not Authority¶

The following establish current state only. They are never canonical, and their durable representation MUST live in the owning project:

docker inspect output · manually created containers · hand-edited systemd units · manually created cron jobs · shell history · ad hoc iptables rules · manually installed binaries · local environment files · one-off compose files · files copied directly onto a host · hand-created Tailscale configuration · manual Cloudflare configuration · local secrets · manually created healthchecks · hidden startup scripts · untracked bind mounts.

This is the deployment-layer instance of the authority hierarchy in the documentation governance standard §3.1: runtime readback is Tier 2 evidence of what is running; it does not become Tier 3 canonical configuration by being observed.

9. Reproducible Infrastructure Is Not Durable Data¶

Do not conflate the two.

Infrastructure and configuration are reproduced from code.
Stateful data is reproduced from backup, replication, and a tested restore procedure.

Mutable production data MUST NOT be committed to Git. Examples of stateful components: Dolt databases, the Drupal content database, durable Redis state, uploaded files, object storage, evidence stores, vector stores where required.

For every stateful component, establish:

DATA_OWNER=  BACKUP=  RETENTION=  RESTORE=  RESTORE_TESTED=  RPO=  RTO=

A restore procedure that has never been executed is RESTORE_TESTED=NO, and the component is not yet reproducible.

10. No Production-Only Fixes¶

When an incident forces a live mutation, the operator MUST:

record the exact live mutation;
create or update the work item immediately;
implement the same fix in source;
deploy from source;
prove the source deployment reproduces the state;
remove the manual residue;
close only after rebuild-safe verification.

An emergency mutation without source convergence is mitigation, not completion. It MUST NOT be reported as done, and the work item stays open until step 7 passes.

11. Infrastructure Ownership Boundary¶

This boundary is the deployment-layer expression of the separation in factory-domain-separation-standard.md.

Owner	Owns
IaC project	Host provisioning, OS bootstrap, network primitives, cloud resources, Tailscale/mesh installation, firewall baseline, k3s bootstrap where applicable, storage and mount provisioning
Deployment project (`agent-docker`)	Images, compose definitions, runtime containers, healthchecks, volumes, restart policy, environment wiring
BluCity	Factory operating configuration, Gas City composition, lifecycle, runtime policy, Factory agents, Orders, Formulas, cross-rig behaviour
BluCity-Packs	Reusable compositions and packaged configuration
Application repository	Application-specific runtime configuration
1Password	Secret values
Git	Secret references

Secret values MUST NOT be moved into IaC, deployment definitions, packs, or any Git-tracked file. See authentication-secrets-constitution.md §11.

Routing examples for reproducibility gaps:

Gap	Owner
Missing Oracle systemd template	IaC or the owning deployment repository
Incorrect Docker healthcheck	Owning deployment repository
BluCity runtime config exists only on Oracle	BluCity
Packaged OpenClaw config missing	OpenClaw / deployment owner
Drupal config exists only in the database	The Drupal project
Custom module change not released through Composer	Module repository and consuming project
Cedar policy installed manually	Cedar policy repository / BluCity packaging
Tailscale host setup undocumented or unautomated	IaC

Drupal obeys the same law: a clean deployment MUST reconstruct the intended site configuration from source — composer.json, composer.lock, config/sync, Recipes, and Config Actions — not from a database snapshot.

12. Rebuild Receipt¶

Every project and service must eventually be able to produce:

PROJECT=
SERVICE=

INFRA_DECLARED=
CONFIG_DECLARED=
SECRETS_REFERENCED=
VERSIONS_PINNED=
DATA_BACKED_UP=
RESTORE_DOCUMENTED=
HEALTHCHECK_DECLARED=
AUTOSTART_DECLARED=
NETWORK_DECLARED=
OBSERVABILITY_DECLARED=

MANUAL_ONLY_CHANGES=
LIVE_DRIFT=
UNKNOWN_CONFIGURATION=

CLEAN_REBUILD_POSSIBLE=
CLEAN_REBUILD_VERIFIED=

BEADS=
MRS=

Target:

MANUAL_ONLY_CHANGES=0
LIVE_DRIFT=0
UNKNOWN_CONFIGURATION=0
CLEAN_REBUILD_POSSIBLE=YES