# CX 0.18.0-pre.1

> CX starts from a single axiom: computing is data transformation, nothing more. Languages, frameworks and processes are ceremony around that fact. CX is the principle made a language: transform. CX is a homoiconic data-and-code language: one bracketed element syntax for documents, queries, programs and its own AST. It post-dates every model's training data, so this layer is the context an assistant needs to write it correctly.

Generated from the CX conformance corpus at the v0.18.0-pre.1 cut by scripts/gen_docs/primer_build.cx. Every code example in every file below is a conformance fixture whose output was re-recorded from the v0.18.0-pre.1 binary.

## Start here

- [CX primer for LLM assistants](https://cxhome.org/llm/primer.md): The one file to load before writing CX. The surface taught through runnable examples, a ring decision table, the core idioms, and the anti-patterns that Lisp/Clojure/shell priors produce — each with its real diagnostic — and, near the top, the forms a model arriving from another language reaches for that do not exist, each beside the cx form.

## Building something

- [Playbook: building a production XAP](https://cxhome.org/llm/playbook-xap.md): The full arc for a production feature deployment: authoring and composing feature grammars, derived nouns and deriver principals, the authority model, the *.xap.cxd deployment document and its [runtime] bindings, offline identity bootstrap, the deployment host, and the ux-web hypermedia surface — with what the rulings forbid stated as plainly as what they require.
- [The customization model: what one tenant may change](https://cxhome.org/llm/model-customization.md): The question an adopter asks first and the layer answers in seven places: what a tenant may change, what must change for everyone, how a change reaches a fleet on both the surface and the grammar plane, and why behaviour is not tenant-customizable — the refusals stated as the promise they enforce rather than as friction.

## Contributing to CX

- [Contributor front door: the rules, and what to load](https://cxhome.org/llm/contributor.md): The second read after the primer, for changing CX rather than writing it: the rules for the best long-term change, each citing its decision and the step that holds it, the RS-n standing decisions in the ledger's own words, and the reading order that loads the least for each task.
- [Contributor: architecture](https://cxhome.org/llm/contributor-architecture.md): The two rings and the groups above them, the repository map and the pins the front door builds from (both projected from the registry), the registration hooks that keep the core free of product names, and the two-repository modules.
- [Contributor: design — a surface before its code](https://cxhome.org/llm/contributor-design.md): How a surface gets its decision, ring, group, registry row, spec and corpus before any code: the six-artifact order, the ring questions, the row's columns and where every row lives today, projected from registry/modules.cxd.
- [Contributor: implementation](https://cxhome.org/llm/contributor-implementation.md): Writing V for CX: one V module per directory, imports downward only, the pub surface as the interface, the registration hooks, the front door's assembled build from the pins, and tooling written in CX.
- [Contributor: test](https://cxhome.org/llm/contributor-test.md): Grading the corpus with cx corpus, choosing steps by the computed selection, the umbrellas and the census trio, the two runners, and the step roster the Makefile runs, projected from TEST_TARGETS.

## Reference

- [Reference: the CX data language](https://cxhome.org/llm/reference-data-language.md): Elements, attributes, scalars and their auto-typing, collections, raw text, tables, identity anchors, and the format conversions the data reading offers.
- [Reference: the CX code language](https://cxhome.org/llm/reference-code-language.md): The directive surface — binding, control flow, comprehensions, pattern matching, definitions, pipes, CXPath — and how errors propagate as values.
- [Reference: the standard library](https://cxhome.org/llm/reference-stdlib.md): The bundled module catalog, the [?lib] import form, and the capability each effectful pack requires.
- [Reference: the cx command line](https://cxhome.org/llm/reference-cli.md): The run surface, the convert surface, the subcommand catalog, and the capability grant flags — including the flag-placement rule that silently denies capabilities when broken.
- [Reference: the platform and ecosystem rings](https://cxhome.org/llm/reference-platform.md): The platform group (store, journal, HTTP, XAP host) and the bindings and ecosystem groups (agent interop, feature distribution, language bindings) — what is reachable and how.
- [cx-platform/connector](https://cxhome.org/llm/connector-reference.md): The connector engine every connector feature runs on: the capability check at the effect point, the open handle registry, the token cache, the spend ledger and handle resolution. A pure-CX package (RULED: RS-25, no V code of its own) -- source stdlib/connector.cx, corpus conformance/platform/connector.cxd.
- [cx-platform/sync](https://cxhome.org/llm/sync-reference.md): Incremental sync: the cursor/watermark contract and the three ways a source is captured, reaching store, journal, sched and the connector engine -- source stdlib/sync.cx, corpus conformance/platform/sync.cxd.

## Optional

- [Everything above, concatenated](https://cxhome.org/llms-full.txt): one fetch, the whole layer.