/kernel

name: kernel
description: Use to change the claims catalog (add, amend, retire a claim, cut a catalog pass), to manage editions (add, retire, recompose), to measure an edition's conformance honestly (plant, prove, audit, lower a row), to clear accumulated decisions with the owner, or to check that the whole kernel is still coherent. Also use when a claim or edition change may have left counts, scope or statements in the documentation stale. Do not use it to seed a project from an edition; that is seed's job.

X2 Kernel

Maintain the three artifacts the method is built from, and keep them honest about each other. Run this whenever the answer to "what must be true", "what exists to be measured", or "what do we actually enforce" is about to change.

First, decide whether you were given direction

**Invoked with no direction, this skill EXPLAINS ITSELF AND STOPS.** Print the orientation below, then end the turn and wait. Do not read the tree, do not run a check, do not pick a verb that looks likely, and do not ask a narrowing question that presumes one. Every verb here changes something a person is accountable for, or reports a state that is only worth reporting when someone asked; guessing which one is meant is how a maintenance tool edits a catalog nobody asked it to touch.

**Invoked WITH direction, route it and get on with it.** Most requests name a verb without knowing it: "this claim looks wrong" is `rule`, "does the record still hold" is `verify`, "add a stack" is `edition`. Read the intent and act. Do not make someone who has already said what they want choose from a menu, and do not re-explain the skill to them.

The orientation, printed verbatim when there was no direction

> This skill maintains the kernel: the claims catalog, the editions built against it, and the > conformance record between them. Six things it can do: > > | verb | what it does | say something like | > |---|---|---| > | `status` | reports where everything stands, every number derived from the tree | "where do things stand" | > | `verify` | runs every gate and re-derives every stated fact. Changes nothing | "is the kernel still coherent" | > | `claim` | adds, amends or retires a claim, or cuts a catalog pass | "add a claim about X" | > | `edition` | adds, retires or recomposes an edition | "start an edition for stack Y" | > | `measure` | plants against a claim and records what is honestly enforced | "prove what this edition enforces" | > | `rule` | walks open decisions one at a time and records each with its argument | "clear the open decisions" | > > `status` and `verify` change nothing and are the safe place to start. `claim` and `rule` are owner > decisions and will ask before acting. Tell me which, or just describe what you want to change.

Then stop. The next turn is the user's.

The model, and it is small

| artifact | job | authority | |---|---|---| | the claims catalog, `kernel/claims/` | what MUST be true | **NORMATIVE**. Source of truth | | the conformance record, `kernel/<edition>/conformance.json` | what IS enforced today, one row per claim per edition, pinned to a named catalog pass | **DESCRIPTIVE** | | the editions, `kernel/<edition>/` | the machinery in copyable form. Current state, not aspiration | what new projects seed from |

Call it the **claims catalog**, or **claims**. Never "the catalogue of rules", never "invariants catalog". The vocabulary is load-bearing: a record whose name drifts stops being findable.

**Precedence.** If a document and running code disagree, the code is the FACT and the disagreement is surfaced, never reconciled quietly. Code is evidence of what is true. It is never the authority on what SHOULD be true; that is the catalog's job. Three consequences to hold at once:

• Code violating a claim is wrong code. Fix the code.
• A conformance row that OVERSTATES is a worse defect than the code it hides, because someone can

seed from it. Never leave one standing while deciding what to do.

• Code violating a claim whose row reads `proven` is TWO defects: the code, and the guard that failed

to stop it. **The guard is the more serious one.**

**Congruent with the catalog** means every claim has an HONEST row. It does NOT mean every claim is `proven`. A claim the exemplar has no surface for is correctly `owed`, and an `owed` row with a named trigger is the record being right.

**Never reconcile two editions against each other.** Each record is measured against the catalog independently. Where one edition has a persistence layer and another does not, the same claim is honestly `proven` in one and `owed` in the other. Forcing them to match makes one of them lie.

The verbs

| verb | changes | use when | |---|---|---| | **`claim`** | the catalog | a claim is added, amended or retired, or a catalog pass is cut | | **`edition`** | the editions | an edition joins, leaves, or the shared tier is recomposed | | **`measure`** | the conformance record | a row is planted, proven, audited or lowered | | **`rule`** | a decision | open questions have accumulated and the owner will decide them | | **`verify`** | nothing | check every gate and re-derive every derived fact | | **`status`** | nothing | report where everything stands and what is open |

`verify` and `status` change nothing and are always safe. Prefer them when unsure what state the tree is in. **Never run a mutating verb without knowing the current state**, because a measurement taken from the wrong baseline is worse than no measurement.

---

`status`

Report, in this order, every number DERIVED at runtime and none of it quoted from a document:

1. Claim count, and the catalog pass date. 2. Per edition: the status tally, the non-`owed` count, and which claims those are. 3. Which claims are `owed` in every edition (nothing in any exemplar to enforce) versus enforced somewhere. 4. Open decisions awaiting a ruling, and open findings with a live trigger. 5. Anything `verify` would fail on.

**Never quote