CodeAnvil Model Charter

Version: 1.0

Status: active foundation model

Date: 2026-07-21

System Thesis

CodeAnvil 将声明转化为受治理的运行状态。X-CodeAnvil 是运行在 Cloudflare 生态之上的 CodeAnvil 基础设施生态与品牌运行面；未来的 X、APP、企业管理系统或网站系统是由 CKIMS 分配和治理的独立运行体。

CodeAnvil turns declarations into governed runtime state. X-CodeAnvil is the CodeAnvil infrastructure ecosystem and brand operating surface running on top of the Cloudflare ecosystem. Future X, app, enterprise-management, or website systems are independent runtime bodies allocated and governed by CKIMS.

Canonical Judgment

CodeAnvil, CodeAnvil Kernel, CKIMS, and X-CodeAnvil are not four peer products.

The stable model is:

1. CodeAnvil is the programmable infrastructure and execution system.

2. CodeAnvil Kernel is the deterministic execution kernel inside CodeAnvil.

3. CKIMS is the Human + Agent control plane for operating CodeAnvil.

4. X-CodeAnvil is the unique CodeAnvil infrastructure ecosystem and brand operating surface on `x-codeanvil.io`.

5. Future created systems are independent runtime bodies. In CKIMS 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
        |
        +-- CKIMS
        +-- X-CodeAnvil Ecosystem on x-codeanvil.io
        |     +-- OS Surface
        |     +-- Brand Website Surface
        |     +-- Model/Docs Surface
        |     +-- API Surface
        |     +-- Future X Entry Surfaces
        |
        +-- Platform Services
        +-- State, Event, Policy, Artifact, Release, Domain Ledgers
        |
        v
CodeAnvil Kernel
        |
        v
Cloudflare Application Ecosystem

Non-Negotiable Invariants

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

2. X-CodeAnvil is not a normal instance; it is the CodeAnvil-owned infrastructure ecosystem on top of Cloudflare.

3. CodeAnvil Kernel is an internal deterministic kernel, not the public product name.

4. CKIMS is a control plane, not a public entity interface.

5. X-CodeAnvil must not bypass CKIMS 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. CKIMS 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 CKIMS-governed allocations, not unmanaged servers.

Source Of Truth

The CodeAnvil Model document system is the upper document authority. CKIMS and Kernel ledgers are the runtime authority. Local Work files are temporary intake material only.

Naming And Terminology

Official Names

Boundary Rules

Required Object Vocabulary

Forbidden Naming Patterns

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:

CodeAnvil Kernel

Kernel standard loop:

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

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

CKIMS

CKIMS exposes the same governed fact surface to Human and Agent operators:

CKIMS 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 infrastructure ecosystem and brand operating surface on top of the Cloudflare ecosystem.

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

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 CKIMS `instance` when approved.

X-CodeAnvil itself is not that instance. It is the ecosystem surface through which CodeAnvil, CKIMS, 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:

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

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 / CKIMS / X-CodeAnvil forms a second ecosystem above Cloudflare:

Provider Planes

Current CKIMS Interpretation

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

Risk Scale

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 CKIMS 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:

Implementation Roadmap

Phase 0: Constitution

Deliver:

Exit condition: any Codex entering CodeAnvil can read the model, understand the hierarchy, and continue without guessing.

Phase 1: CodeAnvil Spine

Deliver:

Exit condition: a governed Cloudflare surface can be planned, approved, deployed, verified, audited, and rolled back.

Phase 2: Governed Operations

Deliver:

Exit condition: routine operations no longer depend on ad hoc Codex reasoning.

Phase 3: X Forge

Deliver:

Exit condition: X-CodeAnvil can define an X and ask CodeAnvil to produce its governed runtime.

Phase 4: X Operations

Deliver:

Exit condition: X operational meaning and CodeAnvil infrastructure facts are connected but not confused.

Phase 5: Evolution And Portfolio

Deliver:

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 infrastructure ecosystem surfaces.

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

Planned Subdomains

X / Instance Rule

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

An X becomes operational only when CKIMS has an instance request, resource plan, security profile, allocation records, deployment evidence, and audit trail. Domains and subdomains are assigned by CKIMS 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 CKIMS 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 CKIMS-governed allocations.

Actual Domain Rule

Actual domain count comes from CKIMS 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

Required Library Classes

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. CKIMS 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.

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

Layers

Principal Vocabulary

Email address alone is never the identity authority. It is contact and recovery evidence unless mapped through active `identity_mappings` and CKIMS workseat policy.

Unified Identity Standard

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

CKIMS Access Model

CKIMS should be protected before broad public use by Cloudflare Access or an equivalent Zero Trust gate. Cloudflare Access authenticates the operator; CodeAnvil Kernel authorizes the operation 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 CKIMS identity policy.

An X instance may manage:

An X instance must not:

Email Relationship

CodeAnvil Email Management System supplies identity messages, not identity authority.

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

ZeptoMail is planned as 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 CKIMS has provider evidence, DNS plan, rollback evidence, Owner approval, deployment record, and verification audit.

Machine Rules

CodeAnvil Model Reconstitution And Local Boundary

Version: 1.0

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. CKIMS is the durable system. The CodeAnvil Model is the upper authority. CKIMS ledgers, documents, operations, reports, work queue, approvals, and audit entries are the runtime authority.

Correct Layer Order

Codex / Human
  -> local CodeAnvil BootstrapEntry
  -> CodeAnvil Kernel
  -> CKIMS
  -> 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 CKIMS.

Local Boundary Standard

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 /ckims/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 CKIMS 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 CKIMS 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 CKIMS has accepted migration evidence.

CKIMS Required Planes

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

Decision

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

CKIMS Agent Assistant Readonly Plan

Version: 1.0

Status: active readonly planning gate

Date: 2026-07-22

Purpose

CKIMS needs a bounded assistant for routine infrastructure understanding, not an unbounded autonomous operator. The first assistant is read-only. It gathers CKIMS 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

Safety Boundary

The assistant may:

The assistant may not:

AI Model Selection Gate

Workers AI model selection must be data driven. Before testing any model, CKIMS 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. CKIMS allowed use cases

10. CKIMS forbidden use cases

Privacy rule: do not select models from providers headquartered in China for private CKIMS 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:

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 CKIMS.

6. Configure AI Gateway before test.

7. Run one synthetic report over redacted CKIMS sample data.

8. Human/Codex review output quality and cost.

Decision

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

CKIMS 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 CKIMS 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:

Selection Rules

Initial Candidate Classes

Excluded At This Gate

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

This is a CKIMS 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.

CKIMS AI Gateway Synthetic Report Test

Version: 1.0

Status: active synthetic test gate

Date: 2026-07-22

Purpose

This gate verifies that CKIMS 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 CKIMS evidence.

Gateway Policy

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

Configuration target:

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:

The first prompt must not include:

Expected Output

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

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 CKIMS.

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

Deployment Lock

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

CKIMS Readonly Collector Contract

Version: 1.0

Status: active contract gate

Date: 2026-07-22

Purpose

This document defines the first CKIMS 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:

Forbidden first collector sources:

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:

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 CKIMS.

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.

CKIMS Readonly Collector Manual Dry Run

Version: 1.0

Status: active execution gate

Date: 2026-07-22

Purpose

This gate runs the first manual CKIMS readonly collector dry run.

It validates that CKIMS 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 CKIMS.

Allowed Reads

This gate may read:

Forbidden Reads And Writes

This gate must not:

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. CKIMS D1 counts are collected.

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

4. The report is written to CKIMS.

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

CKIMS 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 CKIMS 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:

First Schedule

Recommended first schedule:

Report Storage

Use the existing CKIMS R2 bucket unless a later capacity or separation gate requires another bucket.

Recommended object prefixes:

Queue And Workflow Names

Planned Queue:

Planned Workflow:

Approval Rules

Owner approval is required before:

Acceptance

PASS means:

1. The scheduled scan plan is registered in CKIMS.

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.

CKIMS Agent Assistant Scheduled Scan Deployment Readiness

Version: 1.0

Status: active readiness gate

Date: 2026-07-22

Purpose

This gate prepares CKIMS 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:

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 CKIMS.

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.

CKIMS Agent Assistant Scheduled Scan Provider Execution

Position

This document is the governed provider execution record for the CKIMS scheduled readonly scan runtime.

The runtime belongs to CodeAnvil Kernel Infrastructure Management System / CKIMS. 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:

Runtime Boundary

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

The scheduled runtime reads CKIMS 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 `ckims-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 CKIMS can decide whether to run AI daily, weekly, or only on anomaly.

Success Criteria

Follow-Up Gates

CKIMS Console OS Domain Binding

Position

`os.x-codeanvil.io` is the formal Human-facing operating system domain for CodeAnvil Kernel Infrastructure Management System / CKIMS.

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

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

CKIMS Console OS Language Governance

Position

`os.x-codeanvil.io` is the Human-facing CodeAnvil Kernel Infrastructure Management System / CKIMS operating system surface.

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

Default Rule

The default CKIMS 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 CKIMS primitive, Cloudflare provider primitive, API object, security object, or audit object.

Examples:

Future Languages

Additional languages require a later language-pack governance gate.

Each language pack must define:

UI Implementation Gate

The first implementation should add a compact language selector to the CKIMS Console source with:

Boundary

Language selection must not change CKIMS 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`.

CKIMS 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

CKIMS 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 CKIMS 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 CKIMS 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:

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 CKIMS OS.

The user-management surface belongs under:

First Login Rule

First login is an activation ceremony, not registration.

The activation ceremony must include:

Authentication Factor Order

1. Owner creates or invites the email in OS.

2. Login runtime checks that the email already exists in CKIMS 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

CKIMS passwords are activation credentials, not registration tokens.

Password policy:

Runtime Shape

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

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`.

CKIMS OS Native Web Entry

Position

`os.x-codeanvil.io` is the CodeAnvil-owned operating-system web entry.

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

Entry Model

Current Login Rule

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

Security Boundary

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

Provider mutation requires CKIMS 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: `migrating-os-from-access-front-door-to-native-login-entry`.

X-CodeAnvil Ecosystem Runtime

Version: 1.0

Status: active foundation correction

Date: 2026-07-22

Definition

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

It is not a normal CKIMS instance.

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

Canonical Chain

Cloudflare Ecosystem
  -> CodeAnvil
  -> CodeAnvil Kernel
  -> CKIMS
  -> 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:

These are CodeAnvil infrastructure surfaces until CKIMS 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 CKIMS ledgers they are `instances`.

In public or world language they may be called X.

Each independent runtime body can receive:

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:

Governance Rule

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

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

Current Gate

The current priority remains CKIMS itself:

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

2. CKIMS D1 identity and session schema.

3. ZeptoMail verification delivery.

4. Owner user management.

5. Session-protected CKIMS Console.

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