Contract authority for SkillWeave: the core schemas and the taxonomy value set every consumer validates against.

No runtime code. No product logic. This repository is the root of the release graph and has no runtime dependency on skillweave.

Forgejo is canonical; GitHub is the read-only mirror.

Every SDK release carries the built wheel, the sdist and a SHA256SUMS file with one SHA-256 checksum per distribution file. Download all three assets — the wheel, the sdist and SHA256SUMS — into one directory, verify the downloads, then install the wheel:

sha256sum -c SHA256SUMS
pip install skillweave_sdk-0.3.1-*.whl

SHA256SUMS lists the wheel and the sdist, so all three files must sit in the same directory and sha256sum -c SHA256SUMS must report OK for both before you install. The assets are built deterministically from the tagged commit, so the checksum of a given release is stable and can be republished. The sdist is published alongside the wheel for source installs.

If you cannot fetch the release assets, install from the annotated tag:

pip install "git+https://git.langevc.com/skillweave/[email protected]"

This path does not verify a published checksum; prefer the release assets.

This SDK owns the contract — the authoritative value set of schema and vocabulary, not every line of code that touches it.

skillweave-sdk        owns the CONTRACT    (schemas, taxonomy value set)
skillweave            owns EXECUTION       (runtime, kernel, engine)
skillweave-profiles   owns OPINION         (profiles, category packs)
skillweave-packs-pro  owns COMMERCIAL OPINION (provider-bound)

Concretely, on the state vocabulary: run-state.schema.json#/properties/state/enum carries the value set. The core carries RunStateModel (the member names) and legal_transitions (execution semantics). A validator needs only the value set — that is the argument for an external pack author being able to validate without core access.

schema_version.toml → schema.version. A breaking change raises the major, an additive one the minor. A consumer pins an exact version and validates against it; it never references "latest".

The distribution version in pyproject.toml is the same number, asserted by tests/test_version_agrees.py rather than derived, so neither file silently follows the other.

Consumers keep a guard that compares their value sets against the pinned SDK version. Break a contract here and the consumer's build goes red. The proof is only delivered once a deliberately broken contract turns the other repository's build red — not when the pipeline is green.