Sley

Sley 1.x Legacy / Apache-2.0

Sley 1.x Legacy

The completed human-readable line - frozen, self-hosted, and preserved. Sley 1.2.0 is the final 1.x release-candidate boundary. Active development now lives in the intentionally incompatible machine-native Sley 2.x lineage.

Legacy lineage · frozen · Apache-2.0

Sley 1.x is complete - and stays open

  • 1.x is frozen: no active feature development on the human-readable architecture.
  • v1.2.0 is the final/current legacy release-candidate boundary - Linux x86_64, unsigned provenance, not a production promotion.
  • Human-readable canonical source is the 1.x review projection; self-hosted 1.x compiler owns parser, checker, lint, runtime, bootstrap, and report semantics in Sley source.
  • License: Apache-2.0 - confined to the Sley 1.x Legacy lineage. Active Sley 2 is LicenseRef-Proprietary.
  • Original workflow: structural inspection (AST, graph slices, queries), planned edits, deterministic receipts, and authority gates - the structural, agent-native workflow that Sley 1.x proved.
  • Compatibility: intentionally incompatible with machine-native Sley 2.x. No migration tooling is promised.

Release-candidate proof surface

v1.2.0 release evidence - auditor packet

  • 38 release targets · 99 report schemas · 187 contract fixtures · 72 corpus cases · 264 integration checks · 11 release-packet checks · 4 public-release checks
  • Self-hosted compiler exercised through the verification surface; public shell wraps that language-owned core into a practical local command surface
  • Sensitive host-facing behavior through deterministic authority gates - not implicit live provider/shell/network/secret/payment actions
38 / 38release targets
99report schemas
187 / 187contract fixtures
264 / 264integration checks
Legacy repositoryv1.2.0 releaseClaim evidence

When to use Sley 1.x Legacy

  • Historical compatibility, study, experimentation, forks, or community-led legacy upgrades
  • Verification-friendly structural workflows with human-readable canonical source
  • Any lane where the self-hosted 1.x compiler and existing v1 gate are the desired boundary

When to use active Sley 2

  • New work that needs machine-native typed state, deterministic roots, and proposal-validated transactions
  • Lanes requiring explicit policy/capability and native branch ancestry over verified receipts
  • Active pre-release engineering - inspect the public source directly; no GA or package is claimed

Sley 2 technical brief · Architecture walkthrough · Sley 2 FAQ