core-ai-native

The AI-Native Code Discipline v0.2 (BETA) - language-independent principles, pattern cards, executable-scaffold catalog, and raid playbook for code optimized for comprehension and safe modification by AI agents

**Discipline v0.2 · status: BETA · supersedes DISCIPLINE-CHARTER-v0.1**

**Discipline v0.2 · status: BETA · T1 · supersedes part of GUIDE-SPEC-AUTHORING-v0.1**

**Discipline v0.2 · status: BETA · T1**

**Discipline v0.2 · status: BETA · T1**

**Discipline v0.2 · status: BETA · T1 · language-neutral**

**Discipline v0.2 · status: BETA · T1 · language-neutral**

**Discipline v0.2 · status: BETA · T1 · language-neutral · OPTIONAL but preferred**

**Discipline v0.2 · BETA · appendix · GENERATED from findings.jsonl (A2: derived, do not hand-edit)**

**Discipline v0.2 · BETA · appendix**

`org.vibevm.ai-native/core-ai-native@1.0.0` contributes a boot snippet: text that a session reads before it starts work, placed into the project's generated boot lane by `vibe install`. It is not read on this page — it is read by the agent.

This project follows the AI-Native Code Discipline.

**Status.** Beta; one of three sibling C++ profiles (`cpp-traditional`, `cpp-modern`, `cpp-misra2008`). Sections isomorphic vertically and horizontally. **Precedence rule of this profile:** where a Discipline binding and a MISRA guideline conflict, MISRA wins; the Discipline may only *add* strictness, never relax — the same only-stricter direction the GRP matrix itself enforces.

**Status.** Beta; one of three sibling C++ profiles (`cpp-traditional`, `cpp-modern`, `cpp-misra2008`). Sections isomorphic vertically (Rust/TS/Python guides) and horizontally (sibling profiles). Profile granularity is per build target; cross-profile boundaries follow the adopted-code semantics referenced in the Traditional guide's header.

**Status.** Beta; one of three sibling C++ profiles (`cpp-traditional`, `cpp-modern`, `cpp-misra2008`). Section structure is isomorphic vertically (to the Rust/TS/Python guides) and horizontally (across the three profiles — diff them; the profiles rewire *bindings*, never principles). Profile granularity is **per build target**: one repository may host targets under different profiles; a cross-profile boundary is treated as an adopted-code relationship (see `GUIDE-CPP-MISRA2008-v0.1.xml` §0, which imports that semantics from MISRA Compliance:2020 §6).

**Status.** Beta; fifth language guide. Sections isomorphic to the Rust/TS/Python/C++ guides — diff them across languages; that is the genre's contract.

**Status.** Beta; overlay on `GUIDE-JAVA-v0.1.xml`. Composes with the Spring overlay (Boot AOT) and with Jakarta-family runtimes built for ahead-of-time CDI; only named sections are rewired.

**Status.** Beta; overlay on `GUIDE-JAVA-v0.1.xml`. Composes with the GraalVM overlay via build-time-CDI runtimes; never with the Spring overlay (one container per target). Only named sections rewired.

**Status.** Beta; overlay on `GUIDE-JAVA-v0.1.xml` (the trunk). Only the sections named here are rewired; everything else — carrier, naming, errors-as-sealed-results, suppression policy, risk rows — is inherited. Composition: combines with the GraalVM overlay (Spring Boot AOT); never with the Jakarta overlay (one container per target).

**Status.** Beta; sixth language. Java ships as a **trunk plus three overlays**, in the owner's priority order: this trunk, then `GUIDE-JAVA-SPRING`, `GUIDE-JAVA-GRAALVM`, `GUIDE-JAVA-JAKARTA`. An overlay presupposes the trunk and rewires only the sections it names; everything unstated is inherited. **Composition matrix:** SPRING+GRAALVM legal (Boot AOT); JAKARTA+GRAALVM legal (build-time CDI implementations); SPRING+JAKARTA illegal (one container per target). Sections remain isomorphic to the other language guides — diff them.

**Status.** Beta; seventh language. One document by the owner's structure: **Part I is the trunk** (core Kotlin), **Parts II–IV are inline area overlays** that inherit it and rewire only named sections. The trunk is sovereign — Kotlin Multiplatform makes the JVM just one target, so this is *not* an overlay on the Java trunk; instead, Part II **composes** with the Java ecosystem overlays (Spring) at the JVM, and Part IV defines the Discipline's first **inter-trunk boundary** (Kotlin/JS ↔ `GUIDE-TYPESCRIPT`). Sections stay isomorphic to the other guides.

**Status.** Beta; third T2 guide. Section structure is isomorphic to `GUIDE-RUST-v0.1.md` and `GUIDE-TYPESCRIPT-v0.1.xml` — the guides are meant to be diffed across languages. Scope: only what the axioms require.

**Status.** Beta; second T2 guide. Section structure is deliberately isomorphic to `GUIDE-RUST-v0.1.md` — cross-language diffing of the guides is a feature of the discipline, not a coincidence. Scope: only what the axioms require; formatting and generic style live in tooling.

What `org.vibevm.ai-native/core-ai-native@1.0.0` declares about itself. Everything on this page is the package's own manifest, read and shown — nothing here is an opinion about the package.

**Status.** Beta.

**Status.** Design, beta.

**Status.** Design, beta.

**Status:** SHIPPED with discipline-core 0.6.0 (MCP-SOVEREIGNTY-PLAN Wave 2); the flow foundation is named core-ai-native since the package-family rename (PROP-028), and the crate ships as core-ai-native-mcp.

**Status.** Design proposal v0.1 — not implementation-locked.

The README of `org.vibevm.ai-native/core-ai-native@1.0.0`, as the package ships it.