Joule Code is the coding cargo class of the substrate: a coding operation — an edit, refactor, or generated function — is a content-addressed, signed transition over a source tree, resolved through the energy-tiered cascade (L0 Cache → L1 Lawful → L2 Embed → L3 Model → L4 Wire, stop-at-first-close) with a signed JWP receipt (measured + estimated µJ, honest Provenance) per operation. The agent schema is JouleClaw; L4 frontier agents are reached over ACP with the credential held by the vendor's own client — no protocol token, no required contact with any single company. Stands up the standard to the family schema: - README, SPEC.md (RFC-2119 normative), dual licence (Apache-2.0 code / CC-BY-4.0 spec), ROADMAP, CONTRIBUTING, CHANGELOG. - spec/: cargo (the coding-operation type), cascade (the tier binding), receipt (the JWP energy record), collab (federated, interface-level/Research). - vocab/LEXICON.md. - conformance/v1/: C1 content-addressing, C2 signing, C3 receipt, C4 cascade vectors + VERSIONS + regeneration; real Ed25519 RFC-8032 KATs, derived fields regenerated against the reference library. - joule-code-rs/: lean reference library (schema, cargo, receipt, cascade, conformance). cargo test --workspace passes; the conformance harness runs 11 pass / 0 fail / 7 skip (derived fields pending regeneration). Single-endpoint operation is the v0.1 surface; federated collaboration is specified at interface level and classified Research. Registers the standard in the family README. Co-Authored-By: Claude Opus 4.8 <[email protected]>
1.3 KiB
1.3 KiB
Joule Code Conformance Vector Pack — Version Matrix
Tracks the correspondence between vector-pack versions and Joule Code spec versions.
Matrix
| Vector pack | Spec version | Spec source | Status | Notes |
|---|---|---|---|---|
v1/ |
v0.1.0-draft | ../SPEC.md |
DRAFT | Reference vectors; regenerated against joule-code-rs (see v1/regeneration.md). |
Future entries are appended below this table when a new spec version is introduced. Older entries are never removed.
Version compatibility rules
- Per-spec-major-version packs. Each major spec version has exactly one vector-pack directory (
v1/,v2/, ...). The pack is the canonical conformance suite for that spec version. - No backporting of incompatible vectors. A vector depending on wire-format behaviour introduced in a later spec version is never added to an earlier pack.
- Suites are additive within a pack. New positive/negative vectors may be added to an existing pack as long as they conform to that pack's spec version; a previously-passing implementation must continue to pass.