Version 1.0

CodeAnvil / CodeAnvil Kernel / CodeAnvil Kernel OS / X-CodeAnvil

CodeAnvil 将声明转化为受治理的运行状态;CodeAnvil Kernel 是部署在 Cloudflare Ecosystem 之上的运行内核与操作系统;X-CodeAnvil 是 x-codeanvil.io 上的 CodeAnvil 品牌与 Kernel OS 生态面。

CodeAnvil Model Charter

Version: 1.1

Status: active foundation model

Date: 2026-07-22

System Thesis

CodeAnvil 将声明转化为受治理的运行状态。

CodeAnvil Kernel 是当前部署在 Cloudflare Ecosystem 之上的 CodeAnvil 运行内核、治理内核和操作系统。

X-CodeAnvil 是 `x-codeanvil.io` 上的 CodeAnvil 品牌与 Kernel OS 生态面。

未来的 X、APP、企业管理系统或网站系统,是由 CodeAnvil Kernel 分配和治理的独立运行体。

CodeAnvil turns declarations into governed runtime state.

CodeAnvil Kernel is the CodeAnvil runtime kernel, governance kernel, and operating system currently deployed on top of the Cloudflare Ecosystem.

X-CodeAnvil is the CodeAnvil brand and Kernel OS ecosystem surface on `x-codeanvil.io`.

Future X, app, enterprise-management, or website systems are independent runtime bodies allocated and governed by CodeAnvil Kernel.

Canonical Judgment

CodeAnvil, CodeAnvil Kernel, and X-CodeAnvil are the stable top-level names.

The retired name `CodeAnvil Kernel OS` must not be used as a forward system layer, product name, dashboard label, public surface, or new document title.

The stable model is:

1. CodeAnvil is the programmable infrastructure and execution system.

2. CodeAnvil Kernel is the Cloudflare-backed runtime kernel and operating system inside CodeAnvil.

3. CodeAnvil Kernel OS is the Human + Agent operating surface.

4. X-CodeAnvil is the CodeAnvil brand and Kernel OS ecosystem surface on `x-codeanvil.io`.

5. Future created systems are independent runtime bodies. In Kernel ledgers they are called `instances`; in world narrative and brand language, the created thing may be called `X`.

Layer Order


Human / Codex / External Systems / Unknown Intent
        |
        v
CodeAnvil
        |
        +-- CodeAnvil Kernel
        |     +-- Kernel OS on os.x-codeanvil.io
        |     +-- State, Event, Policy, Artifact, Release, Domain Ledgers
        |     +-- Provider, Security, Identity, Mail, R2, AI, Workflow Governance
        |
        +-- X-CodeAnvil Ecosystem on x-codeanvil.io
        |     +-- Brand Website Surface
        |     +-- Model/Docs Surface
        |     +-- API Surface
        |     +-- Future X Entry Surfaces
        |
        v
Cloudflare Ecosystem

Non-Negotiable Invariants

1. CodeAnvil Kernel can operate CodeAnvil even before any future X instance exists.

2. X-CodeAnvil is not a normal instance. It is the CodeAnvil-owned brand and Kernel OS ecosystem on top of Cloudflare.

3. CodeAnvil Kernel is the operating kernel, not just an internal component name.

4. CodeAnvil Kernel OS is a control surface, not a public entity interface.

5. X-CodeAnvil must not bypass CodeAnvil Kernel to mutate Cloudflare resources.

6. Kernel must not own X business meaning, value judgment, or governance semantics.

7. Every state change has principal, plan, authorization, execution, verification, and evidence.

8. Cloudflare is the current runtime substrate, not the domain identity of CodeAnvil.

9. Codex is the current primary Agent Operator, not the only possible agent.

10. Conversation is never the final source of truth; it is compiled into model, plan, decision, ledger, or evidence.

11. Kernel object vocabulary uses `instance`; public/world vocabulary may use `X`.

12. `x-codeanvil.io` is the X-CodeAnvil brand IO and CodeAnvil infrastructure ecosystem domain. It must be governed as a CodeAnvil foundation domain asset, not as a future instance domain.

13. Future X/APP/enterprise/website systems may be Cloudflare-native independent runtime bodies similar to VPS tenants in ownership boundary, but they remain Kernel-governed allocations, not unmanaged servers.

Source Of Truth

The CodeAnvil Model document system is the upper document authority.

CodeAnvil Kernel ledgers are the runtime authority.

Local Work files are temporary intake material only.

Naming And Terminology

Official Names

NameRoleChinese Definition
CodeAnvilInfrastructure and execution system用于部署、运行、治理和观察数字系统的可编程基础设施与执行系统
CodeAnvil KernelCloudflare-backed runtime kernel and operating systemCodeAnvil 当前部署在 Cloudflare Ecosystem 之上的运行内核、治理内核、数据内核和 Human + Agent 操作系统
CodeAnvil Kernel OSOperating surface`os.x-codeanvil.io` 上的 CodeAnvil 原生操作系统入口;由 CodeAnvil Kernel 授权、记录和治理
X-CodeAnvilBrand and Kernel OS ecosystem surface`x-codeanvil.io` 上的唯一 CodeAnvil 品牌与 Kernel OS 生态面;承载 CodeAnvil Model、OS、API、网站及未来 X 入口
XWorld narrative object未来由 CodeAnvil Kernel 创建和运行的世界叙事对象;在系统治理、资源分配和运行时账本中映射为 `instance`
InstanceIndependent runtime bodyCodeAnvil Kernel 中被申请、计划、分配资源、部署、运行和审计的独立运行体;对外叙事可表现为 X、APP、企业系统、网站系统或其他系统
X-CodeAnvil IOBrand and infrastructure IO`x-codeanvil.io`,X-CodeAnvil 的品牌 IO 与 CodeAnvil 基础设施生态域

Retired Names

NameStatusRule
CodeAnvil Kernel OSretiredDo not use as a forward system layer, product name, UI label, public surface, or new document title. Existing historic IDs must be migrated or treated as legacy evidence.

Boundary Rules

  • CodeAnvil is not equal to CodeAnvil Kernel.
  • CodeAnvil Kernel is not a future X instance; it is the operating kernel.
  • X-CodeAnvil is not a Cloudflare dashboard, not a generic CMS, and not a normal instance.
  • `x-codeanvil.io` is the CodeAnvil-owned ecosystem domain. It may host OS, docs, APIs, website, and future X entry surfaces, but these surfaces are infrastructure surfaces until CodeAnvil Kernel allocates a separate instance boundary.
  • Future created systems are Kernel-governed instances; in world narrative they may be X.
  • Enterprise, dashboard, portal, visualization, VPN, and application are future instance types or X meanings, not top-level Kernel allocation targets.
  • X is a governed world narrative root object, not a loose project folder.
  • Required Object Vocabulary

    TermMeaning
    PrincipalHuman, Agent, service, or X identity that can be authenticated and authorized
    WorkseatScoped operating role used by Human or Agent
    Desired StateDeclared target state
    Actual StateProvider-observed runtime state
    PlanOrdered, explainable transition from actual to desired state
    ApprovalExplicit authorization bound to a target
    ExecutionA concrete attempt to apply an approved plan
    EvidenceMachine-readable proof of source, action, verification, or result
    X ManifestCanonical root specification for a governed X entity
    X Runtime InstanceKernel instance created from an X Manifest and governed by CodeAnvil Kernel
    Independent Runtime BodyA Kernel-governed allocation that can contain its own website, app, data, mail sender, storage, jobs, and security profile; similar to a VPS tenant boundary but Cloudflare-native by default

    Forbidden Naming Patterns

  • Do not introduce CodeAnvil Kernel OS as a new top-level name.
  • Do not call CodeAnvil Kernel a public brand surface.
  • Do not count DNS records, Pages URLs, Worker default domains, or Access domains as actual domains.
  • Do not use enterprise, application, or dashboard as Kernel allocation target types. Use `instance` or `infrastructure`.
  • Do not rename Kernel instances to enterprise objects in system ledgers. Use enterprise only as an `instance_type`, request purpose, or X semantic layer when needed.
  • Do not treat `x-codeanvil.io` as a random deployment domain or as a future instance domain. It is the governed X-CodeAnvil brand and infrastructure IO.
  • System Architecture

    CodeAnvil

    CodeAnvil accepts declarations, policies, artifacts, approvals, and operating commands. It returns governed runtime state, deployment evidence, resource state, audit history, and reconciliation signals.

    Core planes:

  • Identity and Workseat
  • Resource Registry
  • Domain and Surface Registry
  • State and Event Ledger
  • Policy and Authorization
  • Artifact and Release Registry
  • Workflow and Job Services
  • Observability and FinOps
  • Recovery and Rollback
  • Cloudflare Provider Layer
  • CodeAnvil Kernel

    CodeAnvil Kernel is the Cloudflare-backed runtime kernel and operating system of CodeAnvil.

    Kernel standard loop:

    
    Declare -> Validate -> Diff -> Plan -> Authorize -> Apply
       ^                                               |
       |                                               v
    Reconcile <- Observe <- Record <- Verify <---------
    

    CodeAnvil Kernel receives authorized state changes, produces plans, applies provider operations through controlled drivers, verifies results, records evidence, and reconciles drift.

    CodeAnvil Kernel OS

    CodeAnvil Kernel OS exposes the same governed fact surface to Human and Agent operators:

  • Panorama
  • Governance OS
  • Resource plans
  • Domains
  • Foundation assets
  • Provider contracts
  • Runbooks
  • Approvals
  • Work queue
  • Operations and audit
  • CodeAnvil Kernel OS does not replace Cloudflare Dashboard. It defines which provider actions are allowed, why they are allowed, who approved them, what evidence exists, and how any future operator continues.

    X-CodeAnvil

    X-CodeAnvil is the unique CodeAnvil brand and Kernel OS ecosystem surface on top of the Cloudflare ecosystem.

    It contains the CodeAnvil-facing surfaces that make the infrastructure visible and operable:

  • `os.x-codeanvil.io` for the native CodeAnvil Kernel OS.
  • model/docs surfaces for the CodeAnvil Model and governance standards.
  • API surfaces for governed Human, Codex, and service entry.
  • brand and website surfaces for X-CodeAnvil public narrative.
  • future X entry surfaces allocated through CodeAnvil Kernel.
  • X-CodeAnvil may also turn unknown inputs into X Manifest and governed X:

    
    Unknown -> Candidate X -> Specified X -> Forgeable X -> Commissioned X -> Operational X -> Evolved X
    

    The digital runtime portion of a future X is compiled into CodeAnvil deployment specifications and becomes a Kernel `instance` when approved.

    X-CodeAnvil itself is not that instance. It is the ecosystem surface through which CodeAnvil, CodeAnvil Kernel, Human, Codex, and future X runtime bodies meet.

    Independent Runtime Bodies

    Future APP, enterprise-management, website, portal, community, dashboard, VPN-connected, or X systems are independent runtime bodies.

    They are similar to VPS tenants in boundary and responsibility, but Cloudflare-native by default:

  • Pages or Workers for web and API runtime.
  • D1, KV, Durable Objects, R2, Queues, Workflows, Cron, and Hyperdrive for state, storage, coordination, and jobs.
  • WAF, Rate Limiting, Turnstile, API Shield, Access, and Zero Trust for security.
  • Workers AI, AI Gateway, Vectorize, and AI Search when approved by CodeAnvil Kernel policy.
  • A VPS is reserved for needs Cloudflare cannot reasonably satisfy, such as long-lived custom processes, unsupported runtimes, specialized network daemons, or workloads with constraints outside the Cloudflare execution model.

    Contract Between X-CodeAnvil And CodeAnvil

    ContractDirectionMeaning
    Capability CatalogCodeAnvil -> X-CodeAnvilCurrent infrastructure capability and constraints
    Deployment SpecificationX-CodeAnvil -> CodeAnvilCompiled runtime request for a future independent runtime body
    Plan And Risk ReportCodeAnvil -> X-CodeAnvilDiff, cost, risk, approval requirements
    Authorization DecisionHuman/X-CodeAnvil -> CodeAnvilApproval, rejection, or conditions
    Runtime StateCodeAnvil -> X-CodeAnvilHealth, version, cost, resource, deployment state
    X ContextX-CodeAnvil -> CodeAnvilX identity, budget, owner, lifecycle boundary; Kernel stores runtime governance as an instance

    Cloudflare Provider Model

    Cloudflare is the current CodeAnvil runtime substrate. CodeAnvil should be Cloudflare-native first, while keeping its domain model independent from Cloudflare product names.

    CodeAnvil / CodeAnvil Kernel / X-CodeAnvil forms a second ecosystem above Cloudflare:

  • Cloudflare provides provider primitives.
  • CodeAnvil turns provider primitives into governed infrastructure capabilities.
  • CodeAnvil Kernel operates those capabilities for Human and Codex.
  • X-CodeAnvil exposes the CodeAnvil brand and Kernel OS ecosystem through `x-codeanvil.io`.
  • Future independent runtime bodies receive allocated capabilities from CodeAnvil Kernel instead of directly owning provider sprawl.
  • Provider Planes

    CodeAnvil PlaneCloudflare CapabilitiesCodeAnvil Use
    Domain EntryRegistrar, DNS, Proxy, RoutesBrand domains, endpoint routing, actual-domain vs child-record governance
    Performance And AvailabilityCache, CDN, Smart Routing, Load BalancingTraffic posture and production readiness
    SecurityWAF, Rate Limiting, API Shield, TurnstileEdge and API protection policy
    RuntimeWorkers, Pages, Containers, Workers for PlatformsAPIs, consoles, future hosted instances
    Data And StateD1, R2, KV, Durable Objects, HyperdriveLedgers, objects, config, coordination, external DB acceleration
    AutomationQueues, Workflows, Cron TriggersAsync work, durable multi-step execution, retries
    AIWorkers AI, AI Gateway, Vectorize, AI Search, AgentsOptional acceleration and model mediation
    Zero TrustAccess, Tunnel, SWG, DLP, RBI, CASBBreakglass access, private connectivity, future VPN-like posture

    Current CodeAnvil Kernel Interpretation

  • D1 is the structured system ledger.
  • R2 is the object, package, document, and evidence store.
  • Workers are API and Kernel runtime.
  • Pages hosts Human-facing consoles and document systems.
  • Access protects breakglass, private, and Zero Trust surfaces. The normal `os.x-codeanvil.io` entry uses CodeAnvil-native login and Kernel authorization.
  • Domain assets are first-class CodeAnvil Kernel foundation assets.
  • DNS records, Worker default domains, Pages deployment URLs, Access app domains, and aliases are child evidence.
  • Binding Rule

    When running inside Workers or Pages Functions, Cloudflare bindings are preferred over REST API calls for bound resources. REST API access remains a provider administration path used by local owner-deploy scripts and must be governed by provider contracts and LocalOnly secrets.

    Provider Execution Policy

    Provider-side create, change, delete, or route mutation requires:

    1. Resource plan.

    2. Owner approval.

    3. Active provider execution policy.

    4. Active runbook.

    5. Rollback or compensation evidence.

    6. Deployment ledger record.

    7. Route smoke and inventory audit.

    8. Audit log.

    Security, Governance, And Audit

    Principal Model

    Human, Codex, autonomous agents, services, and X entities are principals. They operate through scoped workseats or service contracts.

    Core Rules

  • Least privilege by default.
  • Plan-first for R2 and above risk.
  • Owner approval for provider-side create/change/delete.
  • No raw provider secret may enter Work, public source, cloud ledger payloads, or R2 documents.
  • Production operations require rollback or compensation.
  • Every operation is append-only in operations and audit ledgers.
  • Work queue owns continuation state, not conversation memory.
  • Risk Scale

    RiskMeaningDefault
    R0Read-onlyAutomated allowed
    R1Reversible development changeFast review or policy auto-approval
    R2Production reversible changePlan and explicit approval
    R3Data, deletion, cost, or access impactOwner approval plus backup/rollback
    R4Irreversible, legal, capital, entity terminationHuman Principal only

    Evidence Chain

    
    Intent
      -> Plan
      -> Approval
      -> Provider Execution Policy
      -> Runbook
      -> Deployment / Change Record
      -> Verification
      -> Audit
      -> Continuation State
    

    Identity Mapping

    Cloudflare Access identity must be mapped into CodeAnvil Kernel OS workseats through `identity_mappings`. Owner capability is never inferred from email alone unless the mapping is active and audited.

    Formal identity, passkey, MFA, OIDC, and X instance SSO rules are defined by `08-IDENTITY-ACCESS-GOVERNANCE.md`.

    Break-Glass

    Emergency access must include:

  • Reason.
  • Time boundary.
  • Actor.
  • Target.
  • Recovery plan.
  • Follow-up audit.
  • Owner review.
  • Implementation Roadmap

    Phase 0: Constitution

    Deliver:

  • CodeAnvil Model document system.
  • Naming and terminology standard.
  • Domain and surface registry.
  • CodeAnvil Kernel OS provider execution policy.
  • Runbook and rollback standard.
  • Exit condition: any Codex entering CodeAnvil can read the model, understand the hierarchy, and continue without guessing.

    Phase 1: CodeAnvil Spine

    Deliver:

  • Kernel API and D1/R2 ledgers.
  • CodeAnvil Kernel OS Governance OS.
  • Work queue continuation.
  • Domain and foundation asset governance.
  • Provider contract and owner decision flow.
  • Exit condition: a governed Cloudflare surface can be planned, approved, deployed, verified, audited, and rolled back.

    Phase 2: Governed Operations

    Deliver:

  • Access identity mapping.
  • Provider-side execution runbooks.
  • Drift and inventory reconciliation.
  • Cost and quota posture.
  • More complete dashboard/operator UX.
  • Exit condition: routine operations no longer depend on ad hoc Codex reasoning.

    Phase 3: X Forge

    Deliver:

  • X Manifest schema.
  • X Definition Engine.
  • X Compiler to CodeAnvil deployment specification.
  • First minimal X.
  • Exit condition: X-CodeAnvil can define an X and ask CodeAnvil to produce its governed runtime.

    Phase 4: X Operations

    Deliver:

  • X runtime state.
  • X metrics.
  • X operating tasks.
  • X governance decisions.
  • Exit condition: X operational meaning and CodeAnvil infrastructure facts are connected but not confused.

    Phase 5: Evolution And Portfolio

    Deliver:

  • X lineage graph.
  • Replication, split, merge, suspend, retire.
  • Portfolio-level governance.
  • Exit condition: multiple X entities can evolve while preserving model, evidence, and audit.

    Domain And Surface Registry

    Brand Domain

    `x-codeanvil.io` is the active X-CodeAnvil brand IO and the governed parent domain for CodeAnvil Kernel OS ecosystem surfaces.

    This domain is a CodeAnvil foundation asset, not a normal instance domain. Its subdomains are created through CodeAnvil Kernel resource plans and domain records, not ad hoc dashboard edits.

    Planned Subdomains

    HostRoleSurface
    `www.x-codeanvil.io`X-CodeAnvil brand frontPublic CodeAnvil/X-CodeAnvil narrative front
    `docs.x-codeanvil.io`CodeAnvil document systemModel, standards, runbooks
    `model.x-codeanvil.io`CodeAnvil Model canonical entryModel index and architecture docs
    `os.x-codeanvil.io`CodeAnvil Kernel OSCodeAnvil-native login and operating console
    `dashboard.x-codeanvil.io`DashboardsFuture governed dashboard surfaces
    `visual.x-codeanvil.io`Visualization assetsFuture governed visualization registry
    `api.x-codeanvil.io`API entryFuture provider-routed API entry
    `breakglass.x-codeanvil.io`Emergency accessCloudflare Access protected fallback

    X / Instance Rule

    Public language uses X. Kernel system language uses `instance`.

    An X becomes operational only when CodeAnvil Kernel has an instance request, resource plan, security profile, allocation records, deployment evidence, and audit trail. Domains and subdomains are assigned by CodeAnvil Kernel to infrastructure or instances; no X receives ad hoc DNS or storage.

    `x-codeanvil.io` is different from a future X instance domain. It is the CodeAnvil-owned ecosystem domain where Kernel OS, model docs, APIs, brand website, and future X entry surfaces can exist under governed allocation.

    Future systems may each operate as independent website/app/system bodies on Cloudflare, similar to VPS tenant boundaries, but they remain Kernel-governed allocations.

    Actual Domain Rule

    Actual domain count comes from CodeAnvil Kernel foundation assets with `asset_type=domain` only.

    DNS records, Pages URLs, Worker default domains, Access application domains, aliases, routes, and deployment URLs are child records/evidence.

    Creation Rule

    No subdomain becomes official until it has:

    1. Domain asset or parent domain record.

    2. Resource plan.

    3. Surface record.

    4. Owner approval when public or production.

    5. Deployment or route record.

    6. Audit entry.

    Document Library Governance

    Principle

    CodeAnvil is a growing architecture system. Its standards must be organized as document systems, not isolated notes.

    The CodeAnvil Model document system is the upper authority. Specialized document systems extend it.

    Current Document Systems

    Document SystemRoleStatus
    CodeAnvil ModelNaming, model, architecture, Cloudflare provider mapping, security, domain, roadmapactive
    CodeAnvil Email SystemEmail identity delivery, Zoho Mail, Cloudflare DNS, mailbox governance, ZeptoMail transactional gate planningactive foundation ready
    X ManifestX to CodeAnvil Kernel OS instance request compiler standardactive foundation draft

    Required Library Classes

  • Model and terminology.
  • Architecture.
  • Provider integration.
  • Deployment.
  • Security and identity.
  • Data and state.
  • Domain and DNS.
  • Email and communication.
  • Runbooks.
  • Instance templates.
  • Verification and audit.
  • Registry Rule

    Every document system must have:

    1. Index JSON.

    2. Charter.

    3. Technical architecture document.

    4. Security/governance document.

    5. Runbook or execution model.

    6. D1 `document_ledger` records.

    7. D1 `persistent_ledger` source bundle.

    8. CodeAnvil Kernel OS route or model endpoint when it must be machine-readable.

    Extension Rule

    Future CodeAnvil technical, architecture, deployment, and provider libraries should be added as sibling document systems under `BootstrapEntry`, then uploaded into CodeAnvil Kernel ledgers.

    Identity And Access Governance

    Position

    CodeAnvil identity is a Kernel infrastructure concern. It is not owned by any single X instance, enterprise management system, website, or community system.

    CodeAnvil Kernel owns the identity and access governance model for Human + Codex operation. X instances consume governed identity assertions and manage their own business roles under Kernel policy.

    Layers

    LayerRoleAuthority
    CodeAnvil KernelDurable identity evidence, workseats, operations, audit, approvalsKernel ledger and OS
    CodeAnvil Kernel OSHuman + Codex entry, provider execution, resource allocation, governance actionsNative login plus Kernel workseat mapping
    CodeAnvil Email PlaneVerification, recovery, security, and transactional message deliveryKernel email policy
    X instanceBusiness users, instance roles, customer profiles, service permissionsInstance policy constrained by CodeAnvil Kernel

    Principal Vocabulary

  • `principal`: Human, Codex, service, agent, or external identity subject.
  • `workseat`: operating seat that grants scoped Kernel capability.
  • `identity_mapping`: audited link between an external identity provider subject and a Kernel workseat.
  • `x_user`: a user record inside a future X instance.
  • `instance_role`: role or permission set inside one X instance.
  • `customer_profile`: business profile inside a website, portal, community, or application instance.
  • Email address alone is never the identity authority. It is contact and recovery evidence unless mapped through active `identity_mappings` and Kernel workseat policy.

    Unified Identity Standard

    The unified identity center is a CodeAnvil Kernel infrastructure standard. It should support:

  • Email registration and verification for approved users only.
  • Immutable user ID.
  • Username and display name governance.
  • Passkey-first login.
  • TOTP MFA as fallback.
  • Recovery codes and account recovery.
  • Mandatory administrator MFA.
  • OIDC SSO for CodeAnvil Kernel OS and future X instances.
  • CodeAnvil Kernel OS Access Model

    CodeAnvil Kernel OS uses CodeAnvil-native login as the normal user experience.

    Cloudflare Access remains a breakglass and private-surface control. It must not be the public-facing login page for `os.x-codeanvil.io`.

    CodeAnvil Kernel authorizes operations through workseats, approvals, provider contracts, resource plans, and audit.

    Codex access is not a free-floating role. Codex enters through the local bootstrap entry, reads Kernel context, and acts as a scoped operator under AIP and workseat rules.

    X Instance SSO Model

    Future enterprise, website, community, dashboard, portal, and VPN systems are X instances or instance types. They may accept OIDC SSO from the CodeAnvil identity center, but they do not own Kernel identity policy.

    An X instance may manage:

  • Employee roles and business permissions.
  • Customer profiles, orders, and service permissions.
  • Teacher, learner, group, and read-only permissions.
  • Instance-local admin roles.
  • An X instance must not:

  • Create unmanaged provider identity resources.
  • Treat email as the only proof of ownership.
  • Bypass Kernel approval for privileged administrator access.
  • Create mail, DNS, storage, or security resources outside Kernel allocation.
  • Email Relationship

    CodeAnvil Email Plane supplies identity messages, not identity authority.

    Zoho Mail provides governed human mailboxes such as `owner@x-codeanvil.io`.

    ZeptoMail is the transactional delivery provider for verification, recovery, MFA, security alert, admin notification, and future X instance transactional mail. It must not be activated for a sending domain until CodeAnvil Kernel has provider evidence, DNS plan, rollback evidence, Owner approval, deployment record, and verification audit.

    Machine Rules

  • CodeAnvil Kernel owns the identity standard.
  • Email providers deliver messages; they do not define identity.
  • `identity_mappings` and `workseats` are the Kernel authority for CodeAnvil operators.
  • X instances consume identity assertions and manage instance-local authorization.
  • Passkey-first and mandatory admin MFA are target security posture.
  • OIDC is the standard federation surface for future X instances.
  • No provider-side identity, mail, DNS, or access mutation may bypass the CodeAnvil Kernel Provider Execution Gate.
  • CodeAnvil Model Reconstitution And Local Boundary

    Version: 1.1

    Status: active reconstitution gate

    Date: 2026-07-22

    Purpose

    This document corrects CodeAnvil from an expanding local context folder into a governed cloud operating model.

    The local `CodeAnvil/` root is only an entry and temporary work surface. CodeAnvil Kernel is the durable system. The CodeAnvil Model is the upper authority. Kernel ledgers, documents, operations, reports, work queue, approvals, and audit entries are the runtime authority.

    Correct Layer Order

    
    Codex / Human
      -> local CodeAnvil BootstrapEntry
      -> CodeAnvil Kernel
      -> Cloudflare infrastructure ledgers and operating surfaces
    

    `Work/` is not memory. `MemorySync/` is not permanent truth. `LocalOnly/` is credential custody only. Any durable item must be compiled into CodeAnvil Kernel.

    Local Boundary Standard

    Local roleDirectoryAllowed contentNot allowed
    Bootstrap Entry`BootstrapEntry/`Entry packet, source for Kernel Worker, source documents, governed deploy scripts, local route smoke toolsAd hoc task memory that CodeAnvil Kernel cannot read
    LocalOnly`LocalOnly/`One `.env.template` and one real `.env` per provider authorityDuplicated secret files, ungoverned provider credentials
    Temporary Work`Work/`Files actively downloaded or generated for one current taskLong-term model, context, docs, evidence archive
    Transitional Mirror`MemorySync/*.json`Temporary evidence mirrors until migrated to Kernel ledgersTreated as source of truth

    Reconstitution Rule

    The single CodeAnvil Model document system is the constitution of the system. New architecture, provider setup, domains, email identity, dashboards, AI assistants, work queues, and X instances must be registered against this model.

    Codex must not rely on old conversation inference. On entry Codex reads:

    1. `GET /entry`

    2. `GET /panorama`

    3. `GET /kernel/operating-system`

    4. `GET /work-queue?status=active`

    5. the target route named by the active work item

    Memory Retirement Policy

    Local `MemorySync/*.json` files are migration candidates. They may remain as mirrors while CodeAnvil Kernel OS is still being built, but they must not define the system.

    Retirement sequence:

    1. Inventory local memory mirrors.

    2. Classify each mirror as credential-boundary, deploy evidence, operation evidence, obsolete diagnostic, or temporary task state.

    3. Register active evidence in Kernel D1 and object evidence in R2 where needed.

    4. Replace repeated context files with work queue entries and operation logs.

    5. Keep `MemorySync/current-agent-context.json` only as a thin local pointer until `/entry` and `/panorama` fully replace it.

    6. Delete or archive retired mirrors only after CodeAnvil Kernel has accepted migration evidence.

    CodeAnvil Kernel Required Planes

    CodeAnvil Kernel OS must expose a Codex-operable overview before any enterprise or X instance is created:

  • model plane
  • panorama plane
  • provider capability plane
  • foundation asset plane
  • domain and route plane
  • data and object plane
  • security and identity plane
  • work queue plane
  • operation and audit plane
  • document plane
  • AI assistant report plane
  • Decision

    CodeAnvil local remains small. CodeAnvil Kernel OS becomes the operating system. The CodeAnvil Model becomes the upper standard that both Human and Codex can read before performing work.

    CodeAnvil Kernel OS Agent Assistant Readonly Plan

    Version: 1.0

    Status: active readonly planning gate

    Date: 2026-07-22

    Purpose

    CodeAnvil Kernel OS needs a bounded assistant for routine infrastructure understanding, not an unbounded autonomous operator. The first assistant is read-only. It gathers CodeAnvil Kernel OS and Cloudflare posture, asks an approved Workers AI model to summarize and classify, then writes reports and suggested work items for Codex and Human review.

    Cloudflare Capability Fit

    CodeAnvil Kernel OS needCloudflare capabilityInitial mode
    Scheduled scanWorkers Cron TriggersDaily or manual readonly trigger
    Cloudflare and CodeAnvil Kernel OS collectionWorker + Cloudflare REST API + D1Read-only
    Durable multi-step report runWorkflowsPlanned after readonly report contract
    Async jobs and retriesQueuesPlanned after report contract
    Structured stateD1Active ledger target
    Report objectsR2Planned object target
    Text analysisWorkers AICandidate selection required
    Usage visibilityAI GatewayRequired before model testing
    Semantic retrievalVectorize / AI SearchLater, only after document corpus quality gate
    Long-running interactive agentAgents / Durable ObjectsLater, after approval and permission model

    Safety Boundary

    The assistant may:

  • read CodeAnvil Kernel OS D1 ledgers
  • read Cloudflare inventory through a scoped token
  • read route smoke results
  • summarize current posture
  • classify risk, drift, and missing governance
  • create report records
  • propose work queue items with `pending-owner-review` status
  • The assistant may not:

  • write DNS
  • deploy Workers or Pages
  • mutate R2 buckets
  • rotate or read secrets
  • send email
  • approve its own plan
  • close tasks without Human or Codex action
  • AI Model Selection Gate

    Workers AI model selection must be data driven. Before testing any model, CodeAnvil Kernel OS records:

    1. model identifier

    2. model provider or organization

    3. hosting/runtime provider

    4. supported task type

    5. pricing/cost metric

    6. context limits or input constraints when available

    7. data retention and privacy posture

    8. jurisdiction and provider exclusion notes

    9. CodeAnvil Kernel OS allowed use cases

    10. CodeAnvil Kernel OS forbidden use cases

    Privacy rule: do not select models from providers headquartered in China for private CodeAnvil Kernel OS infrastructure summaries, private logs, owner identity context, or provider configuration analysis.

    Initial accepted task class is `infrastructure-summary-and-risk-classification`, not code execution and not provider mutation.

    Report Contract

    Each report writes:

  • `report_id`
  • `scan_scope`
  • `scan_started_at`
  • `scan_completed_at`
  • `input_evidence_refs`
  • `model_candidate_id`
  • `ai_gateway_ref`
  • `summary`
  • `findings`
  • `recommended_work_items`
  • `risk_level`
  • `human_review_required`
  • `mutation_performed=false`
  • First Test Sequence

    1. Register the readonly plan.

    2. Register model candidate fields and selection policy.

    3. Read current Cloudflare Workers AI model catalog through official source or Cloudflare API.

    4. Shortlist several non-China-hosted/provider-suitable models.

    5. Register cost/security comparison in CodeAnvil Kernel OS.

    6. Configure AI Gateway before test.

    7. Run one synthetic report over redacted CodeAnvil Kernel OS sample data.

    8. Human/Codex review output quality and cost.

    Decision

    CodeAnvil Kernel OS Agent Assistant v1 is a reporting and recommendation assistant. It is not an autonomous infrastructure mutator.

    CodeAnvil Kernel OS Workers AI Model Candidate Registry

    Version: 1.0

    Status: active candidate registry

    Date: 2026-07-22

    Purpose

    This registry records the first Workers AI model candidates for CodeAnvil Kernel OS Agent Assistant v1. It is a selection gate, not an inference deployment.

    The goal is to find a safe, low-cost, non-China-provider model for readonly infrastructure summaries, governance-gap classification, and report drafting.

    Official Evidence

    Official Cloudflare sources used:

  • Workers AI model catalog: `https://developers.cloudflare.com/workers-ai/models/`
  • Workers AI pricing: `https://developers.cloudflare.com/workers-ai/platform/pricing/`
  • Workers AI data usage: `https://developers.cloudflare.com/workers-ai/platform/data-usage/`
  • Workers AI REST API: `https://developers.cloudflare.com/workers-ai/get-started/rest-api/`
  • AI Gateway: `https://developers.cloudflare.com/ai-gateway/`
  • Selection Rules

  • Do not choose China-headquartered model providers for private CodeAnvil Kernel OS infrastructure summaries.
  • Prefer Cloudflare-hosted models.
  • Prefer low output-token cost for daily reports.
  • Prefer models suitable for summarization, risk classification, and structured text.
  • Use AI Gateway before inference testing.
  • Do not send secrets, owner identity details, private tokens, or raw provider credentials to the model.
  • Do not grant mutation capability.
  • Initial Candidate Classes

    CandidateProviderStatusReason
    `@cf/ibm-granite/granite-4.0-h-micro`IBMpreferred-first-testVery low listed cost and suitable for lightweight infrastructure summaries
    `@cf/meta/llama-3.1-8b-instruct-fp8-fast`MetacandidateLow listed input cost and practical report generation
    `@cf/meta/llama-3.2-3b-instruct`MetacandidateSmall model for low-risk summaries and classification
    `@cf/google/gemma-4-26b-a4b-it`GooglecandidateBalanced price and capability for more complex summaries
    `@cf/openai/gpt-oss-20b`OpenAIcandidateReasoning-capable model, moderate listed cost

    Excluded At This Gate

    Models from DeepSeek, Zhipu/Z.ai, Qwen, Moonshot/Kimi, and BAAI are excluded from private CodeAnvil Kernel OS infrastructure-summary use at this gate because the current privacy rule excludes China-headquartered providers for private infrastructure analysis.

    This is a CodeAnvil Kernel OS policy decision, not a judgment of model quality.

    Deployment Lock

    No AI inference is enabled by this registry. The next action is AI Gateway setup and a redacted synthetic report test.

    CodeAnvil Kernel OS AI Gateway Synthetic Report Test

    Version: 1.0

    Status: active synthetic test gate

    Date: 2026-07-22

    Purpose

    This gate verifies that CodeAnvil Kernel OS can use Cloudflare AI Gateway and Workers AI for a bounded, observable, low-risk report workflow.

    This is not a production assistant deployment. It is a single synthetic test over redacted fake CodeAnvil Kernel OS evidence.

    Gateway Policy

    Gateway ID: `kernel-agent-assistant-v1`

    Configuration target:

  • collect logs: enabled
  • cache TTL: `0`
  • rate limit: disabled at this first test gate
  • retries: not used at this first test gate
  • mutation authority: none
  • Test Model

    Initial model: `@cf/ibm-granite/granite-4.0-h-micro`

    Selection reason: low listed Workers AI cost and non-China-provider policy fit for infrastructure summaries.

    Synthetic Input Only

    The first prompt may include:

  • fake CodeAnvil Kernel OS counts
  • fake route status
  • fake work queue samples
  • fake governance gaps
  • non-secret system names
  • The first prompt must not include:

  • API tokens
  • owner identity details
  • real raw provider logs
  • raw DNS record values beyond public domain names
  • private emails beyond already-governed public role labels
  • R2 object contents
  • Expected Output

    The model should produce concise JSON-like report content containing:

  • summary
  • findings
  • recommended work items
  • risk level
  • human review required
  • Acceptance

    PASS means:

    1. AI Gateway is listed or created.

    2. The Workers AI request is routed through the gateway.

    3. A model response is returned.

    4. A sanitized report record is written to CodeAnvil Kernel OS.

    5. No provider infrastructure mutation is performed beyond AI Gateway creation if missing.

    Deployment Lock

    After this test, CodeAnvil Kernel OS Agent Assistant remains readonly. Scheduled scans, Cron, Queues, Workflows, and R2 report objects require later gates.

    CodeAnvil Kernel OS Readonly Collector Contract

    Version: 1.0

    Status: active contract gate

    Date: 2026-07-22

    Purpose

    This document defines the first CodeAnvil Kernel OS readonly collector contract for the Agent Assistant.

    The collector is the deterministic evidence layer. Workers AI may summarize only the evidence produced by this contract. The assistant must not independently discover secrets, mutate providers, deploy Workers, change DNS, send mail, approve actions, or expand scope.

    Scope

    Allowed first collector sources:

  • CodeAnvil Kernel OS D1 ledgers
  • Cloudflare account inventory metadata
  • Cloudflare zone and DNS metadata
  • Cloudflare Worker, Pages, D1, R2, AI Gateway, and Access metadata
  • public domain names and provider resource names
  • non-secret deployment, route, status, count, and timestamp evidence
  • Forbidden first collector sources:

  • API tokens
  • OAuth refresh tokens
  • raw mailbox content
  • private owner identity values
  • raw request bodies containing personal data
  • raw DNS secret-adjacent values unless already public and required for verification
  • R2 object bodies
  • provider logs that have not passed a redaction gate
  • Redaction Rules

    Every collector output must:

    1. replace token-like strings with `[redacted-token-like-value]`

    2. replace email local parts unless the address is an approved public role address

    3. store raw evidence references separately from AI prompt content

    4. include `synthetic_input_only` or `redacted_input_only`

    5. include `mutation_performed: false`

    Report Shape

    Required report fields:

  • `report_id`
  • `collector_contract_id`
  • `scan_scope`
  • `scan_started_at`
  • `scan_completed_at`
  • `input_evidence_refs`
  • `redaction_policy_id`
  • `model_id`
  • `ai_gateway_id`
  • `summary`
  • `findings`
  • `recommended_work_items`
  • `risk_level`
  • `human_review_required`
  • `mutation_performed`
  • Execution Phases

    Phase 1: contract only.

    Phase 2: manual readonly collector dry run.

    Phase 3: scheduled Cron collector.

    Phase 4: Queue-backed evidence processing.

    Phase 5: Workflow-backed review and approval loop.

    Phase 6: low-risk auto-remediation proposals only. Provider mutation remains locked unless a separate execution gate is approved.

    Acceptance

    PASS means:

    1. The collector contract is registered in CodeAnvil Kernel OS.

    2. A redaction policy is active.

    3. A manual readonly collector dry-run task is created.

    4. No provider API read or write is executed by this contract gate.

    5. AI inference remains limited to the previous synthetic test until the manual dry-run gate is implemented.

    CodeAnvil Kernel OS Readonly Collector Manual Dry Run

    Version: 1.0

    Status: active execution gate

    Date: 2026-07-22

    Purpose

    This gate runs the first manual CodeAnvil Kernel OS readonly collector dry run.

    It validates that CodeAnvil Kernel OS can gather limited infrastructure metadata, redact it, pass only the redacted summary through Cloudflare AI Gateway and Workers AI, and write a human-reviewed report back to CodeAnvil Kernel OS.

    Allowed Reads

    This gate may read:

  • Cloudflare account metadata
  • Cloudflare Workers script names
  • Cloudflare D1 database names
  • Cloudflare R2 bucket names and metadata
  • Cloudflare Pages project names
  • Cloudflare Queue names
  • Cloudflare Access application names
  • Cloudflare AI Gateway names
  • Cloudflare zone names and status
  • CodeAnvil Kernel OS D1 table counts
  • CodeAnvil Kernel OS active work queue summary
  • Forbidden Reads And Writes

    This gate must not:

  • read provider secrets
  • read R2 object bodies
  • read mailbox content
  • write DNS
  • deploy Workers or Pages
  • create, delete, or mutate Cloudflare infrastructure
  • send email
  • approve its own recommendations
  • AI Prompt Boundary

    Workers AI receives only a compact redacted evidence summary. Raw Cloudflare API bodies must not be sent to the model.

    Acceptance

    PASS means:

    1. Cloudflare metadata reads succeed or fail with sanitized diagnostics.

    2. CodeAnvil Kernel OS D1 counts are collected.

    3. The AI report is generated through `kernel-agent-assistant-v1`.

    4. The report is written to CodeAnvil Kernel OS.

    5. The next gate is scheduled scan planning, not autonomous remediation.

    CodeAnvil Kernel OS Agent Assistant Scheduled Scan Plan

    Version: 1.0

    Status: active planning gate

    Date: 2026-07-22

    Purpose

    This document defines the first scheduled readonly scan plan for the CodeAnvil Kernel OS Agent Assistant.

    The plan converts the manual readonly collector dry run into a governed automation design using Cloudflare Cron Triggers, Queues, Workflows, R2, D1, Workers AI, and AI Gateway.

    This gate is a plan only. It must not enable Cron, create queues, deploy Workflows, write R2 report objects, mutate Cloudflare provider resources, send email, or auto-remediate infrastructure.

    Runtime Composition

    Recommended composition:

  • Cron Trigger starts a scheduled scan.
  • Worker builds a scan job envelope.
  • Queue buffers the scan job and prevents direct long-running Cron execution.
  • Workflow coordinates collection, redaction, AI report generation, D1 writes, and review task creation.
  • R2 stores report objects and redacted evidence bundles.
  • D1 stores report metadata, task state, approvals, operations, and audit events.
  • AI Gateway records model usage, observability, and cost signals.
  • Workers AI summarizes only redacted evidence.
  • First Schedule

    Recommended first schedule:

  • cadence: daily
  • cron expression: `17 2 * * *`
  • timezone meaning: UTC
  • initial mode: report-only
  • auto-remediation: locked
  • Report Storage

    Use the existing CodeAnvil Kernel OS R2 bucket unless a later capacity or separation gate requires another bucket.

    Recommended object prefixes:

  • `kernel/reports/readonly/daily/`
  • `kernel/reports/readonly/manual/`
  • `kernel/evidence/redacted/`
  • Queue And Workflow Names

    Planned Queue:

  • `kernel-readonly-scan-jobs-v1`
  • Planned Workflow:

  • `kernel-readonly-scan-workflow-v1`
  • Approval Rules

    Owner approval is required before:

  • enabling Cron
  • creating a Queue
  • deploying a Workflow
  • adding Worker bindings
  • writing scheduled report objects to R2
  • sending notifications
  • attempting any provider mutation
  • Acceptance

    PASS means:

    1. The scheduled scan plan is registered in CodeAnvil Kernel OS.

    2. Planned resources are represented as resource plans.

    3. Approval gates are registered.

    4. The next task is a deployment readiness gate.

    5. No Cloudflare provider resources are created or modified by this gate.

    CodeAnvil Kernel OS Agent Assistant Scheduled Scan Deployment Readiness

    Version: 1.0

    Status: active readiness gate

    Date: 2026-07-22

    Purpose

    This gate prepares CodeAnvil Kernel OS scheduled readonly scan automation for owner approval.

    It does not create Cloudflare Queues, enable Cron Triggers, deploy Workflows, change Worker bindings, write R2 report objects, send notifications, or perform provider mutation.

    Readiness Package

    The readiness package contains five approval targets:

  • Cron Trigger for daily readonly scan
  • Queue for scan job buffering
  • Workflow for durable scan orchestration
  • Worker bindings for Queue, Workflow, R2, D1, AI Gateway, and Workers AI
  • R2 report-prefix contract
  • Deployment Order

    After owner approval, deploy in this order:

    1. Create Queue.

    2. Add Worker Queue producer/consumer bindings.

    3. Add scheduled handler and Cron Trigger.

    4. Add Workflow binding and implementation.

    5. Add R2 report write path.

    6. Run manual scheduled simulation.

    7. Enable daily schedule.

    Rollback Rules

    Rollback order:

    1. Disable Cron Trigger.

    2. Pause or remove Queue consumer.

    3. Disable Workflow invocation path.

    4. Lock R2 report write path.

    5. Keep D1 audit and report metadata.

    Acceptance

    PASS means:

    1. The readiness package is registered in CodeAnvil Kernel OS.

    2. Approval ledger rows are created for each planned resource group.

    3. The provider execution gate remains locked.

    4. The next task is owner-approved provider execution.

    CodeAnvil Kernel OS Agent Assistant Scheduled Scan Provider Execution

    Position

    This document is the governed provider execution record for the CodeAnvil Kernel OS scheduled readonly scan runtime.

    The runtime belongs to CodeAnvil Kernel OS. It is not an X instance and it is not an enterprise management system. Its purpose is to give every Human and Codex entry a current operational picture without relying on local conversation memory.

    Approved Execution Scope

    Owner approval allows this gate to create and connect the first scheduled readonly scan chain:

  • Cloudflare Queue: `kernel-readonly-scan-jobs-v1`
  • Worker Queue binding: `CodeAnvil Kernel OS_READONLY_SCAN_JOBS`
  • Worker scheduled handler: daily Cron trigger
  • Worker queue consumer: `codeanvil-kernel-dev-0001`
  • R2 report prefix: `kernel/reports/readonly/daily/`
  • D1 runtime index: `kernel-agent-assistant-scheduled-scan-runtime-current-v1`
  • Runtime Boundary

    The Worker runtime does not hold the Cloudflare account owner token.

    The scheduled runtime reads CodeAnvil Kernel OS governance ledgers already present in D1, then writes a readonly report to R2 and a machine-readable index to D1. It does not mutate DNS, email, Workers, Pages, D1, R2 bucket definitions, Access, WAF, or account configuration during scheduled execution.

    Provider-wide Cloudflare API reads remain a separate owner-entry collector gate until a narrower Credential Worker or Cloudflare-native credential boundary is designed.

    Deployment Order

    1. Mark the five owner approvals as approved in `approval_ledger`.

    2. Create or reuse Cloudflare Queue `kernel-readonly-scan-jobs-v1`.

    3. Deploy `codeanvil-kernel-dev-0001` with D1, R2, Queue, and AI bindings.

    4. Create or reuse the Queue consumer for `codeanvil-kernel-dev-0001`.

    5. Set the Worker Cron trigger to `17 2 * * *`.

    6. Run a manual scheduled-scan simulation through the Worker route.

    7. Record provider execution evidence, resources, deployment, work queue, operation, and audit rows.

    Rollback Order

    1. Remove or clear the Cron schedule.

    2. Disable or remove the Queue consumer.

    3. Redeploy the Worker without the Queue binding if necessary.

    4. Preserve R2 report objects and D1 audit rows.

    AI Gate

    The first provider execution does not run automatic AI inference in the scheduled Worker.

    Workers AI and AI Gateway remain approved for redacted manual tests. Scheduled AI analysis requires a follow-up cost, privacy, and binding gate so CodeAnvil Kernel OS can decide whether to run AI daily, weekly, or only on anomaly.

    Success Criteria

  • Queue exists or is reused.
  • Worker deploy succeeds and `/kernel/agent-assistant/scheduled-scan-runtime` returns accepted.
  • Cron schedule is present.
  • Manual simulation queues and consumes at least one job.
  • R2 contains a report object under the governed prefix.
  • D1 contains the current runtime record and at least one scheduled readonly scan report index.
  • `work_queue`, `operations`, `deployment_ledger`, `cloud_resources`, and `audit_log` contain execution evidence.
  • Follow-Up Gates

  • Scheduled AI inference cost and privacy gate.
  • Provider-wide readonly collector credential boundary.
  • CodeAnvil Kernel OS front-end operating system report view.
  • Workflows implementation gate if the orchestration needs multi-step retries beyond Queue consumer behavior.
  • CodeAnvil Kernel OS Console OS Domain Binding

    Position

    `os.x-codeanvil.io` is the formal Human-facing operating system domain for CodeAnvil Kernel OS.

    This domain belongs to CodeAnvil infrastructure. It is not an X instance domain and it is not a future enterprise or application system domain.

    Target Binding

  • Hostname: `os.x-codeanvil.io`
  • Cloudflare zone: `x-codeanvil.io`
  • Pages project: `codeanvil-dashboard-shell`
  • Pages target: `codeanvil-dashboard-shell.pages.dev`
  • Surface: CodeAnvil Kernel OS
  • Required Provider Actions

    1. Add `os.x-codeanvil.io` as a Cloudflare Pages custom domain for `codeanvil-dashboard-shell`.

    2. Ensure `os.x-codeanvil.io` has a proxied CNAME to `codeanvil-dashboard-shell.pages.dev`.

    3. Protect `os.x-codeanvil.io` with a Cloudflare Access self-hosted application.

    4. Reuse the existing CodeAnvil Dashboard Shell access posture where possible:

    - allowed identity provider

    - 24h session duration

    - allow Cloudflare account members policy

    5. Register Pages custom domain, DNS, Access app, Access policy, surface, operation, and audit evidence in CodeAnvil Kernel.

    Safety Boundary

    This gate may create or reuse records. It must not delete existing DNS records, remove Access policies, weaken access control, or change email DNS records.

    If an incompatible `os.x-codeanvil.io` DNS record already exists, execution must stop and record a blocked gate.

    Success Criteria

  • Pages custom domain exists for `os.x-codeanvil.io`.
  • DNS CNAME exists and points to `codeanvil-dashboard-shell.pages.dev`.
  • Access application exists for `os.x-codeanvil.io` or a blocked security gate is recorded.
  • CodeAnvil Kernel OS ledgers contain the domain binding evidence.
  • Kernel route smoke and local pass remain accepted.
  • CodeAnvil Kernel OS Console OS Language Governance

    Position

    `os.x-codeanvil.io` is the Human-facing CodeAnvil Kernel OS operating system surface.

    Language selection is a CodeAnvil Kernel OS operating-system capability. It is not an X instance feature and it is not a public brand-site translation feature.

    Default Rule

    The default CodeAnvil Kernel OS language is English.

    English is the canonical machine and operator terminology layer for infrastructure controls, provider records, resource state, audit state, security gates, and queue status.

    Chinese Rule

    Chinese is the first optional Human-facing language.

    Chinese UI text may explain, label, and guide work, but formal system terms must preserve the English term when the term is a CodeAnvil Kernel OS primitive, Cloudflare provider primitive, API object, security object, or audit object.

    Examples:

  • `CodeAnvil Kernel OS`
  • `CodeAnvil Kernel`
  • `Work Queue`
  • `Access`
  • `D1`
  • `R2`
  • `Worker`
  • `Queue`
  • `Cron`
  • `Agent`
  • `Instance`
  • Future Languages

    Additional languages require a later language-pack governance gate.

    Each language pack must define:

  • locale code
  • translation source
  • canonical English term mapping
  • fallback behavior
  • review owner
  • accessibility review
  • release gate
  • UI Implementation Gate

    The first implementation should add a compact language selector to the CodeAnvil Kernel OS Console source with:

  • default `en`
  • optional `zh-CN`
  • persisted local preference only
  • no provider mutation
  • no identity or authorization change
  • no translation of secret, credential, or policy identifiers
  • Boundary

    Language selection must not change CodeAnvil Kernel OS resource identifiers, provider names, audit IDs, route names, security posture, Access rules, or work queue semantics.

    Status

    Current status: `planned-after-os-security-and-route-validation`.

    CodeAnvil Kernel OS Native Owner Login

    Position

    `os.x-codeanvil.io` requires CodeAnvil-native owner login and user management.

    Cloudflare Access is a perimeter and breakglass layer. It is not the final Human-facing CodeAnvil login experience.

    User Creation Rule

    CodeAnvil Kernel OS has no public registration.

    Users are created, invited, activated, suspended, and removed inside the official operating system at `os.x-codeanvil.io`.

    Owner adds each user's email address in CodeAnvil Kernel OS. Users cannot self-register.

    An email submitted on the login page is valid only if it already exists as an OS-managed user record.

    If the email is not present in CodeAnvil Kernel OS user records, the login attempt is rejected. The system must not create a user from a login attempt.

    Owner Bootstrap Rule

    The first governed user is:

  • email: `owner@x-codeanvil.io`
  • role: Owner
  • scope: global CodeAnvil Kernel OS owner
  • status: bootstrap activation required
  • Owner activation requires email verification before OS access.

    Every login requires mailbox verification. Email verification is not a one-time-only registration event.

    After activation, Owner manages users inside CodeAnvil Kernel OS.

    The user-management surface belongs under:

  • `os.x-codeanvil.io/users`
  • `os.x-codeanvil.io/identity`
  • `os.x-codeanvil.io/audit`
  • First Login Rule

    First login is an activation ceremony, not registration.

    The activation ceremony must include:

  • Owner-created email record
  • email verification link or code sent to the user's own mailbox
  • single-use activation token
  • password setup as the first authentication factor
  • passkey setup as a later strengthened factor when browser support is available
  • recovery codes
  • session issuance by CodeAnvil Kernel OS runtime
  • operation and audit records
  • Authentication Factor Order

    1. Owner creates or invites the email in OS.

    2. Login runtime checks that the email already exists in CodeAnvil Kernel OS user records.

    3. Email verification proves mailbox control on every login.

    4. User sets password during first activation.

    5. Returning users pass password verification and fresh mailbox verification.

    6. Recovery codes are generated during activation.

    7. Passkey and TOTP MFA follow as strengthened security gates.

    Password Standard

    CodeAnvil Kernel OS passwords are activation credentials, not registration tokens.

    Password policy:

  • minimum length: 14 characters
  • maximum length: 128 characters
  • allowed style: password manager generated value or long passphrase
  • required complexity: at least three of four classes: uppercase letters, lowercase letters, digits, symbols
  • forbidden content: user's email, local-part, `x-codeanvil.io`, `CodeAnvil`, repeated obvious sequences, or common weak passwords
  • comparison: case-sensitive
  • storage: never plaintext; store only modern password hash records
  • recommended hash: Argon2id when available; otherwise PBKDF2-SHA256 with high iteration count as Cloudflare Workers fallback
  • rotation: no periodic forced rotation unless compromise is suspected
  • reset: always requires mailbox verification and audit record
  • rate limit: required for activation, login, and reset attempts
  • Runtime Shape

    The native login runtime should be implemented by a Cloudflare Worker or Pages Function with:

  • D1 user and session tables
  • D1 activation token table
  • D1 password credential table using modern password hashing
  • unknown-email rejection before sending verification email
  • fresh mailbox verification for every login attempt
  • password policy validator
  • password hash upgrade path
  • HttpOnly secure session cookie
  • ZeptoMail delivery for verification links
  • rate limiting
  • audit logging
  • no public signup route
  • OS user-management routes controlled by Owner policy
  • Temporary Boundary

    Until the native login runtime is deployed, `os.x-codeanvil.io` may show a static CodeAnvil native login page with no credential submission.

    Cloudflare Access remains as breakglass, administrative perimeter, or device posture layer on a separate fallback route or hostname. The user-facing login page is CodeAnvil-owned.

    Status

    Current status: `planned-native-owner-login-runtime`.

    CodeAnvil Kernel OS Native Web Entry

    Position

    `os.x-codeanvil.io` is the CodeAnvil-owned Kernel OS web entry.

    It must not present the Cloudflare Access login page as the normal Human login experience.

    Entry Model

  • `os.x-codeanvil.io`: CodeAnvil native login first.
  • `os.x-codeanvil.io/login`: CodeAnvil native login route.
  • `os.x-codeanvil.io/console`: CodeAnvil Kernel OS Console route after native session runtime is implemented.
  • `breakglass.x-codeanvil.io`: Cloudflare Access protected emergency/admin fallback.
  • Current Login Rule

    The native login page may be static while the runtime is still planned, but it must show CodeAnvil semantics:

  • Owner-added email only.
  • Unknown email is invalid.
  • Every login requires mailbox verification.
  • First activation requires password setup.
  • Public registration is disabled.
  • Security Boundary

    Until CodeAnvil Kernel native auth runtime is implemented, `/console` is a UI source preview and must not perform provider mutation.

    Provider mutation requires Kernel runtime authorization, operation ledger, owner approval where required, and audit.

    Cloudflare Access remains useful as breakglass, but it is not the primary OS login surface.

    Status

    Current status: `kernel-os-native-login-entry-active-runtime-planned`.

    X-CodeAnvil Ecosystem Runtime

    Version: 1.1

    Status: active foundation correction

    Date: 2026-07-22

    Definition

    X-CodeAnvil is the unique CodeAnvil brand and Kernel OS ecosystem surface running on top of the Cloudflare ecosystem.

    It is not a normal instance.

    It is the governed layer where CodeAnvil, CodeAnvil Kernel, Human, Codex, model documents, OS surfaces, APIs, brand websites, and future X entry surfaces meet.

    Canonical Chain

    
    Cloudflare Ecosystem
      -> CodeAnvil
      -> CodeAnvil Kernel
      -> X-CodeAnvil on x-codeanvil.io
      -> Future independent runtime bodies
    

    Active Domain

    `x-codeanvil.io` is the active CodeAnvil infrastructure ecosystem domain.

    It may contain:

  • `os.x-codeanvil.io`: CodeAnvil Kernel OS.
  • model and docs surfaces.
  • API surfaces.
  • public X-CodeAnvil website surfaces.
  • future X entry surfaces.
  • These are CodeAnvil infrastructure surfaces until CodeAnvil Kernel creates a separate instance boundary.

    Future Runtime Bodies

    Future X, APP, enterprise-management, portal, community, dashboard, visualization, or website systems are independent runtime bodies.

    In Kernel ledgers they are `instances`.

    In public or world language they may be called X.

    Each independent runtime body can receive:

  • its own domain or subdomain allocation;
  • its own Pages or Workers runtime;
  • its own D1, KV, Durable Object, R2, Queue, Workflow, Cron, or Hyperdrive allocation;
  • its own sender/mail policy;
  • its own security profile;
  • its own release, audit, and lifecycle records.
  • Cloudflare-Native First

    Future runtime bodies should be Cloudflare-native by default.

    Cloudflare can host website-like systems, app-like systems, APIs, dashboards, portals, background jobs, scheduled workflows, queues, object storage, structured ledgers, and AI-assisted report generation.

    A VPS is considered only when the required workload cannot reasonably fit Cloudflare, such as:

  • long-lived custom processes;
  • unsupported runtime dependencies;
  • specialized network daemons;
  • workload patterns outside Workers, Pages, Containers, D1, R2, Durable Objects, Queues, or Workflows;
  • explicit business or compliance constraints requiring a server boundary.
  • Governance Rule

    No future runtime body may create DNS, storage, mail sender, database, queue, AI route, Access policy, WAF rule, or deployment surface outside Kernel allocation.

    No Codex session should infer the system shape from local files or conversation history. Codex enters CodeAnvil, reads Kernel panorama and work queue, then operates the latest governed model.

    Current Gate

    The current priority remains CodeAnvil Kernel OS:

    1. Native OS login runtime for `os.x-codeanvil.io`.

    2. Kernel D1 identity and session schema.

    3. ZeptoMail verification delivery.

    4. Owner user management.

    5. Session-protected Kernel OS Console.

    6. Continued provider, R2, AI, and domain governance.

    Kernel OS Terminology Simplification

    Version: 1.0

    Status: active naming correction

    Date: 2026-07-22

    Decision

    The retired name `CodeAnvil Kernel OS` is removed from the forward CodeAnvil model.

    The official chain is:

    
    Cloudflare Ecosystem
      -> CodeAnvil
      -> CodeAnvil Kernel
      -> X-CodeAnvil
    

    Reason

    CodeAnvil needs a long-lived ecosystem model with minimal naming load.

    Adding another visible control-plane name creates avoidable friction:

  • Human must learn too many system names before doing work.
  • Codex must resolve an extra abstraction on every entry.
  • Future X/APP/enterprise systems can be confused with the infrastructure control plane.
  • `x-codeanvil.io` should clearly mean CodeAnvil brand plus Kernel OS ecosystem, not a separate management product.
  • Formal Meaning

    CodeAnvil Kernel is the Cloudflare-backed runtime kernel and operating system of CodeAnvil.

    It owns:

  • infrastructure model;
  • provider capability model;
  • Kernel OS;
  • work queue;
  • ledgers;
  • approvals;
  • audit;
  • domain, storage, mail, runtime, AI, and security governance;
  • instance allocation for future independent runtime bodies.
  • X-CodeAnvil is the brand and ecosystem surface on `x-codeanvil.io`.

    It owns:

  • public CodeAnvil/X-CodeAnvil narrative;
  • `os.x-codeanvil.io` Kernel OS entry;
  • CodeAnvil Model and docs surfaces;
  • API surfaces;
  • future X entry surfaces.
  • Migration Order

    1. Update CodeAnvil Model and Kernel OS UI labels.

    2. Add Kernel route aliases for old route paths.

    3. Create Kernel schema migration for future `kernel_*` views or tables.

    4. Rename command IDs only after old aliases continue to resolve.

    5. Retire old public or semi-public surfaces that use the retired name.

    6. Keep audit history immutable.

    Machine Rule

    Codex must not introduce the retired name as a new top-level layer. When reading historic identifiers that contain the retired name, interpret them as CodeAnvil Kernel compatibility records until the Kernel schema migration is complete.

    CA / CK / XC Queue Operating Model

    Version: 1.0

    Status: active upper model

    Date: 2026-07-22

    Purpose

    This document fixes the durable operating boundary for CodeAnvil after the first CodeAnvil Operating System login runtime became active on `os.x-codeanvil.io`.

    The goal is reduction, not expansion: CodeAnvil must remain readable to any Codex agent through a small set of names, queues, logs, and governed component assets.

    Canonical Names

    TermAbbreviationMeaning
    CodeAnvilCAThe subject, brand, and total programmable system.
    CodeAnvil KernelCKThe Cloudflare-backed infrastructure kernel for runtime, storage, development governance, asset governance, AI assistance, queues, logs, deployment, and future instance operation.
    CodeAnvil Operating SystemCA OSThe Human + Codex interaction surface for CodeAnvil control, visualization, monitoring, and queue operation. The active host is `os.x-codeanvil.io`.
    X-CodeAnvilXCThe first X and CodeAnvil's public execution body. It owns the public brand, site, documentation library, source/module development surface, and reusable product assets.
    x-codeanvil.ioXCIOThe X-CodeAnvil brand domain and public domain family.
    Cloudflare EcosystemCFThe provider substrate used by CodeAnvil Kernel.

    Layer Boundary

    
    Cloudflare Ecosystem
      -> CodeAnvil
        -> CodeAnvil Kernel
          -> CodeAnvil Operating System
          -> X-CodeAnvil
            -> future X objects / APPs / websites / systems
    

    CodeAnvil Kernel is not an X. It is the infrastructure and operating kernel.

    X-CodeAnvil is an X. It is also the CodeAnvil public execution body and window into the ecosystem.

    CodeAnvil Kernel Scope

    CK owns the durable infrastructure and machine-readable operating state:

  • runtime layer: Workers, Pages, D1, R2, Queues, Workflows, Email, AI Gateway, Workers AI, DNS, security, and future Cloudflare media/image/video services;
  • event layer: queues, AI collaboration feedback, repair requests, upgrade requests, scan reports, action logs, and audit;
  • resource governance: domains, buckets, databases, API credentials, deployment surfaces, environments, and provider contracts;
  • component governance: reusable source components, module assets, release assets, documentation assets, and upgrade paths;
  • X orchestration: request, plan, allocate, deploy, maintain, upgrade, pause, close, and retire future X runtime bodies.
  • CK does not own public brand narrative or product content except as infrastructure records.

    X-CodeAnvil Scope

    XC owns the first X execution field:

  • public site and brand language;
  • document libraries for technology, narrative, manuals, and public architecture;
  • source/module development for CodeAnvil-facing products;
  • reusable assets such as apps, OS screens, website modules, technical documents, and brand documents;
  • assembly and adaptation of components into future X objects.
  • XC must not directly mutate production runtime objects as a casual development habit. Development flows through components, versions, assets, release candidates, and governed deployment.

    Queue Model

    CK exposes two primary queue lanes:

    Queue LanePurpose
    `ck`Infrastructure, provider, resource, email, AI, DNS, R2, D1, CodeAnvil OS, security, scan, governance, and audit work.
    `xc`X-CodeAnvil public site, documentation library, component development, reusable assets, product assembly, publishing, and maintenance work.

    Every meaningful action must be represented as a queue item.

    Allowed lifecycle:

    
    created -> active -> paused | review | blocked -> active -> closed
    

    Closed work remains audit history. Paused work is resumable without conversation memory. Blocked work must name the blocker. Review work waits for Human or policy acceptance.

    Codex Entry Rule

    On every entry, Codex reads:

    1. CodeAnvil Model;

    2. CodeAnvil Kernel panorama;

    3. CK queue;

    4. XC queue;

    5. latest operation log;

    6. latest AI assistant report.

    Codex should not reconstruct system state from chat memory. If the system cannot answer the entry questions, the next queue item is to repair the system model, not to improvise outside it.

    Component And Asset Rule

    CodeAnvil development moves through stable units:

    
    component source
      -> component version
      -> asset registration
      -> release candidate
      -> X assembly/adaptation
      -> deployment
      -> monitored upgrade path
    

    The CodeAnvil Operating System login surface is the first active example. It must be registered as a reusable component asset before further UI expansion.

    Direct manual edits to running objects are allowed only during early bootstrap or incident repair. Normal future work must upgrade components and then deploy them into X or OS surfaces.

    Immediate Decisions

    1. `os.x-codeanvil.io` is CodeAnvil Operating System, not X-CodeAnvil public site.

    2. `x-codeanvil.io` is the X-CodeAnvil brand domain family.

    3. CK manages the infrastructure for both CA OS and XC.

    4. XC development is delayed until CK queue and component asset governance are visible in CA OS.

    5. The next CodeAnvil OS homepage should show: panorama, CK queue, XC queue, operation log, and AI scan advice.

    Machine Rule

    Do not create new top-level names for this model. Use CA, CK, CA OS, XC, XCIO, and CF. When historic data contains older terms, keep it only as audit evidence and do not let it drive new UI, queue, route, domain, or component naming.

    CodeAnvil Local Thin Entry Closure

    Status: active closure gate

    Date: 2026-07-22

    Authority: CodeAnvil Model

    Purpose

    CodeAnvil local storage must close down to a thin operating entry. Durable model,

    source, queue, operation, asset, report, and audit state belongs to CodeAnvil

    Kernel on Cloudflare.

    The local directory is not the CodeAnvil system. It is a bootloader and temporary

    work seat for Codex and Human operators.

    Formal Local Shape

    AreaPathRule
    Entry`Entry/`Thin bootloader and CodeAnvil Kernel connection contract only.
    LocalOnly`LocalOnly/`Provider credentials and templates only. Real `.env` files are never committed.
    Work`Work/`Temporary task files only. Empty is valid.

    Retired Local Roles

    `BootstrapEntry/` is a migration source, not the formal entry. It may hold local

    copies of CodeAnvil Model documents, Kernel Worker source, CodeAnvil Operating

    System source, scripts, and registries only until cloud readback proves that CK

    can reconstruct the same governed source packages and document libraries.

    `MemorySync/` is a migration cache, not memory. It may hold short evidence files

    only until those files are uploaded to CodeAnvil Kernel or classified as

    disposable. It must not define current truth for Codex.

    CK Closure Gate

    CodeAnvil Kernel is not complete-closure until all of the following pass:

    1. CodeAnvil Model document library can be read from CK without local files.

    2. CodeAnvil Operating System source package can be reconstructed from CK.

    3. CodeAnvil Kernel Worker source package can be reconstructed from CK.

    4. Provider resource ledgers, queues, operations, and audit can be read from CK.

    5. Local `Entry/codeanvil-entry.js` passes CK route smoke checks.

    6. Root `LocalOnly/` contains only approved provider `.env` and `.env.template`

    files.

    7. `Work/` is empty unless an active queue item has checked out real temporary

    work files.

    Operating Rule

    Codex must enter through `Entry/`, then use CK routes for current state:

  • `/entry`
  • `/bootstrap`
  • `/codeanvil-model`
  • `/x/model`
  • `/panorama`
  • `/kernel/summary`
  • `/kernel/queue-system`
  • `/work-queue?status=active`
  • Conversation history and local JSON caches are not operating memory. CK queues

    and operation logs are the durable continuation system.

    Next Implementation Order

    1. Promote `LocalOnly/` to root and update all provider scripts.

    2. Activate `Entry/` as the default local command.

    3. Register this closure rule in CodeAnvil Kernel.

    4. Add CK readback routes for document/source packages where missing.

    5. Audit `BootstrapEntry/` and `MemorySync/` into keep, upload, disposable, and

    delete buckets.

    6. Retire local migration folders only after readback PASS.