Sley 1.2 Is a Release Candidate With Boundaries

What Happened

Sley 1.2.0 reached a public release-candidate boundary. The release line now carries a supported Linux x86_64 artifact path, release validation profiles, checksum and manifest discipline, license and SBOM surfaces, toolchain doctoring, bounded transaction evidence, and a public proof trail that can be inspected outside Greyforge.

The public counts moved as well: 99 report schemas, 187 contract fixtures, 264 integration checks, 38 of 38 v1 targets, 11 of 11 release checks, and 4 of 4 public checks. The supplied release digest is 2765aa5adb09f2ef071b5c97d2726951193b0ac97ddddb9e91e26c5562261838.

Why It Mattered

Sley sits in a category where exaggeration is easy. An agent-native structural programming language can look mature as soon as it produces useful reports and plausible edits. That is not enough. The hard boundary is whether the system keeps evidence, authority, mutation, review, packaging, and publication distinct when the workflow becomes fast.

The 1.2.0 candidate is useful because it does not erase those distinctions. It shows a stronger public surface while retaining the limits that make the evidence credible: Linux x86_64 only, unsigned provenance, no production promotion, and bounded workflow evidence rather than a general benchmark claim.

The Architectural Response

Sley keeps readable source as the review projection and compiler-exposed structure as the work surface. Around that split, the 1.2 line treats inspect, plan, authorize, apply, review, seal, package, and publish as separate surfaces. A report can inform a reviewer without becoming permission. A release verifier can check an artifact without authorizing distribution. A benchmark-like workflow can remain controlled evidence without becoming a universal claim.

That separation is the product. It gives future agents and maintainers a way to inherit structured state without inheriting invisible authority.

What Changed

The public WebForge surface now has to move from an August checkpoint story to a release-candidate story. The earlier guardrails still matter: staged-change validation, read-only bridge access, and report-only structural comparison are part of the lineage. Sley 1.2 adds the release boundary around them.

The result is a cleaner citation point. A reader can inspect the release, follow the claim evidence, read the language and contract documents, and see the boundary conditions without relying on private context.

What Comes Next

The next obligation is synchronization. Repository evidence, product pages, source notes, Chronicles, and future promotion criteria should move together. Counts should stay dated. Controlled evidence should stay bounded. Production claims should wait for production evidence.