leanspec

name

leanSpec

description

Ground every Verity spec question in leanSpec — the single authoritative specification (Python reference implementation), always read from the latest origin/main (lstar HEAD). Use before implementing, reviewing, or answering anything about Verity's protocol behavior, container shapes, constants, fork choice, state transition, signatures, or test vectors. Maps a topic to the authoritative leanSpec path for any protocol element. Triggers: "leanSpec", "leanSpecを確認", "仕様を確認", "Verityの仕様", "prime", "verity context", "where is the spec for", "container shape", "コンテナの形", "3SF", "fork choice", "state transition", "XMSS", "leanVM", "devnet spec", and starting any Verity implementation or review work. Negative triggers: Do NOT activate for pure docs-site work (mdBook page authoring or build/serve). Do NOT activate when working outside the Verity project.

leanSpec — single source of truth for Verity

Verity is a Rust Lean Consensus client. leanSpec (the Python reference implementation) is the only authoritative specification. This skill tells you where the authoritative definition of any protocol element lives, and how to read it correctly.

0. Core principle

• Container shapes, field order, constants, protocol behavior, and conformance test vectors are defined by leanSpec (lstar fork). Verity (Rust) must match it exactly.
• The user-facing docs/ mdBook provides framing but does not override leanSpec. When they conflict, leanSpec wins — treat other docs as possibly lagging.
• Field order is consensus-critical (it determines hash_tree_root). Never reorder.

1. Always read leanSpec from the remote main (no local path assumptions)

Verity targets lstar HEAD (devnet-4/5 are in flight on main), so the spec moves. A pinned commit or a stale local checkout is not the spec. Read the latest of the canonical upstream directly from the remote — this works for every developer and in CI, with no dependency on anyone's local clone path.