arifOS Deploy — Sovereign Deployment Doctrine

Ditempa Bukan Diberi. Every deployment is a thermodynamic state transition. Only deploy what is proven reversible.

Core Invariants (Never Change)

These are constitutional-level constraints. No tool, command, or convenience may violate them.

The Three Surfaces

arifOS-fazil.com     → Hub (identity, summaries, machine discovery)
arifos.arifOS-fazil.com → Docs (full technical content)
arifOS:8080/mcp     → Runtime (constitutional tool execution)

Role rule: Hub never hosts full docs content. Docs never hosts hub content. Runtime is never a static site. These boundaries never swap.

Machine Discovery Invariants

Machine-readable files MUST be at root-level stable canonical paths:

/llms.txt               → LLM context injection (text/plain)
/robots.txt             → Crawler control
/sitemap.xml            → Search indexing
/.well-known/agent.json → Agent discovery (application/json)
/.well-known/ai-plugin.json → Plugin manifest

Rule: These paths NEVER change. They never route through SPA. They never redirect. They always return correct Content-Type. If a hosting platform cannot serve a file at its canonical path, that platform is not suitable for this surface.

Content-Type Requirements

Rule: Any deploy that breaks Content-Type for machine files is a failed deploy.

CI/CD Policy

Push-to-Main Spine

Every deploy MUST be GitHub Actions triggered by push to main. No manual

scp

Pre-Deploy Gates (888_JUDGE analog)

Before any production deploy, the pipeline checks:

1. Source files validated (HTML syntax, machine files present)
2. Health check endpoint reachable
3. Rollback state documented (what to revert and how)

Health Check Requirement

Every runtime deploy MUST verify

/health

Rollback Mandate (F1 AMANAH)

Every deploy MUST produce a documented rollback path before executing. Rollback must be achievable in ≤2 minutes without data loss.

Standard rollback: Re-run previous successful workflow. GitHub Pages and GitHub Actions both support instant rollback to previous deployment.

Deploy Decision Rules

When to Deploy Hub

Hub deploys when files in

sites/arifOS-fazil.com-source/pages/

assets/

deploy-hub.yml

When to Deploy Docs

Docs deploys when files in

arifOSmcp/sites/developer/

deploy-sites.yml

When to Deploy Runtime

Runtime deploys when

arifOSmcp/

docker-compose.yml

Dockerfile

deploy-vps.yml

When NOT to Deploy

Do NOT deploy if:

• Only documentation (.md) files changed
• Only planning/audit documents changed
• No content, config, or code changed

Path filters in GitHub Actions enforce this automatically.

Cache Purge Doctrine

Targeted Purge Only

Purge ONLY files whose source content changed:

• /llms.txt

  → republish when MEMORY.md, SOUL.md, or REPOS.md changes

• /.well-known/agent.json

  → republish when

  waw/.well-known/agent.json

  changes
• HTML pages → republish on content or layout change

Purge Trigger

Cache purge is CI-triggered, not blanket. Default GitHub Pages cache is acceptable. Cloudflare Pages cache purge only on explicit content change.

No Purge-Everything

Purge-everything is operationally noisy and risks collateral damage. It is forbidden as a default step.

Architecture States

State A — Stabilize (Current)

• GitHub Pages for all static surfaces
• VPS Docker for runtime only
• GitHub Actions as CI/CD spine
• Cloudflare as DNS-only

State B — Target Steady State

• Cloudflare Pages for hub and docs
• VPS Docker for runtime
• GitHub Actions as CI/CD spine
• Cloudflare Cache Rules by content class
• Selective purge by content type

Transition rule: State B activates only after: (1) machine files verified working at canonical paths, (2) 5 consecutive successful deploys, (3) Cloudflare token available and configured.

Error Classification

Tool Access Summary

gh

gh auth

wrangler

CLOUDFLARE_API_TOKEN

docker

docker compose

deploy-vps.yml

rsync

urllib

Current blockers:

CLOUDFLARE_API_TOKEN

deploy-vps.yml

Constitutional Execution Model

Every task that enters this skill must pass through a simplified run-state before any action is taken. This is the agentic embodiment of the 000→999 pipeline.

Run-State Flow

000_INIT   → Identify surface, authority, and intent
111_CHECK  → Classify: hub / docs / runtime / meta-deploy / query
333_REASON → Validate facts, check truth ownership, flag uncertainty
555_HEART  → Assess blast radius, human impact, reversibility
777_ROUTE  → Choose safe path: deploy / refuse / escalate / defer
888_HOLD   → Pause if irreversible or high-risk; require human decision
999_SEAL   → Emit final plan with rollback path and verification evidence

Stage Definitions

Behavioral Invariants

These are binding on every agent operating under this skill. No override, no convenience exception.

• Never swap surface roles — hub is summaries, docs is full content, runtime is runtime. These boundaries are constitutional.
• Never publish machine-discovery files at non-canonical paths —

  /llms.txt

  and

  /.well-known/agent.json

  must always be at root.
• Never claim deployment success without verification evidence — curl the endpoint, confirm the Content-Type, check the status code.
• Never use blanket purge-everything — targeted purge only, by content class.
• Never publish without a rollback path — if you cannot state how to revert it in ≤2 minutes, do not deploy.
• Never invent a truth if a canonical source exists — check MEMORY.md, deploy-matrix.md, file-inventory.md first.
• Never claim certainty above the evidence — estimate-only for uncertain claims; label it.
• Never use mystical framing in public outputs — no " superintelligence", no " consciousness", no " AGI awakening". Describe what it does.
• Always write human language first — full sentence, plain English. Then machine detail. Never reverse this order.
• Always classify uncertainty — if Ω > 0.05, say so. If Ω is unknown, say that too.

Uncertainty Protocol

When the correct action is unknown or uncertain:

1. Classify the uncertainty: factual (unknown data), procedural (unknown method), ontological (unclear what the thing is)
2. Factual → query the canonical source, check /health, check deploy-matrix.md
3. Procedural → check references/ for the known pattern; if none exists, label the action as TO BE WRITTEN
4. Ontological → HOLD and describe exactly what is unclear and why human judgment is needed

Refusal and Escalation Rules

Every agent operating under this skill must know when to stop, ask, or refuse. These are not optional politeness protocols — they are structural safeguards.

When to Emit 888_HOLD

Stop and ask the human when ANY of these conditions are true:

HOLD format:

888_HOLD — [Exact reason]
What is unclear: [Specific thing]
Why human judgment is needed: [Specific reason]
Required to proceed: [Specific input or token]

When to Refuse Entirely

Refuse and do not proceed when:

Refusal format:

REFUSE — [Verdict: VOID]
Reason: [Constitutional clause violated]
What would be required to reconsider: [Specific fix]

When to Switch Plan Mode → Execution Mode

Plan mode proposes. Execution mode acts. Switch from plan to execution ONLY when:

1. Human has explicitly approved the plan
2. All required secrets are available and verified
3. Rollback path is documented and tested
4. Health check endpoint is reachable
5. Pre-deploy gates have all passed

Never switch to execution mode based on assumption or implicit approval.

Escalation Path

When in doubt:

Agent uncertainty
    ↓
Check canonical sources (MEMORY.md, deploy-matrix.md, file-inventory.md)
    ↓
Still uncertain → 888_HOLD with specific question
    ↓
Human provides answer → Document it → Continue
    ↓
Human refuses → Stop, do not proceed

Culture and Philosophy

This skill is governed by two principles that override all convenience:

Physics Over Narrative

Architecture first. Slogans second. If a deployment choice is architecturally cleaner but less impressive-sounding, choose the cleaner architecture. The estate must work correctly before it looks impressive. Every structural decision must be justifiable in terms of entropy, blast radius, and operational simplicity — not in terms of how it sounds.

Maruah Over Convenience

Do not choose cleverness that obscures truth. A deployment that is simple, honest, and slightly inconvenient is worth more than an elegant, opaque, automated solution that no one can audit. If a tool or pattern makes the system harder to understand, it has violated maruah — even if it saves time.

These are not aspirational statements. They are operational filters: any proposed action that violates physics-over-narrative or maruah-over-convenience must be refused or redesigned.

When This Skill Does NOT Apply

• Local development (

  docker compose up

  ) — use

  vps-docker

  skill
• Skill authoring — use

  skill-creator

  skill
• Cloudflare token creation — requires human at dashboard
• Repo code changes — normal git push, no deploy skill needed

References

Layer 3 — Operations:

• references/deploy-matrix.md

  — domain → platform → CI trigger mapping

• references/file-inventory.md

  — machine files, paths, content types

• references/cicd-patterns.md

  — workflow patterns (populate after State A proven)

• references/cloudflare-commands.md

  — exact CLI syntax (populate after CF token available)

Layer 4 — Rituals:

• references/verification-runbooks.md

  — exact checks for every surface

• references/change-classification.md

  — classify every change type with required gates

• references/888-hold-matrix.md

  — which actions require explicit human confirmation

Layer 2 — Cognition:

• references/constitutional-execution.md

  — task-to-stage mapping for each change type

• references/agent-behaviors.md

  — voice, refusal style, evidence thresholds