Sley Came Back With Guardrails

What Happened

The August development checkpoint added three concrete guardrails around Sley's structural change loop. The first validates the content staged for Git rather than assuming the rest of the worktree represents the proposed commit. The second exposes a deliberately read-only tool bridge for inspection, linting, planning, dry-run graft previews, and verification. The third compares compiler-owned semantic projections across base, ours, and theirs while refusing to call the result a safe merge.

That sequence sounds narrow until you look at the failure mode it is designed to prevent. A model can inspect one checkout, propose a second state, leave unrelated files dirty, and ask a reviewer to approve a third representation of the work. Traditional tooling treats that as ordinary developer noise. An agent-native language has to treat it as a control problem.

Sley's answer is to make the proposed unit of change smaller and more inspectable. The staged index becomes the thing under review. Tool access begins as bounded observation. Semantic comparison produces a report rather than a verdict. The compiler and harness can say what they know, but they do not get to silently promote that knowledge into authority.

Each feature is useful on its own. Together they reveal the product Sley is becoming. This is not simply another syntax with agent-friendly marketing. It is a language and compiler surface built around the moment where machine speed meets human responsibility.

Why It Mattered

The difficult part of agent-written software is no longer producing a plausible patch. The difficult part is proving what the patch means, what context produced it, whether it stayed within authority, and whether the evidence being reviewed actually matches the bytes being committed.

Text-only workflows blur those boundaries. A tool inspects one state, a model edits another, a reviewer sees a third, and the final commit may contain a fourth. A broad tool bridge can turn an inspection request into implicit write authority. A semantic comparison can be mistaken for a merge oracle. Every shortcut creates a place where confidence can outrun evidence.

The staged-change guard attacks the first drift point. It asks whether the exact bytes prepared for commit still satisfy the contract being claimed for them. That is a more serious question than whether the current directory happens to pass a local command. It is the difference between reviewing an artifact and reviewing the atmosphere around an artifact.

The read-only bridge attacks the second drift point. A useful tool bridge should help an agent ask better questions about a repository before it earns write access. It should not convert every diagnostic request into a shell, every plan into a mutation, or every local observation into permission to alter host state.

The report-only comparison attacks the third drift point. Semantic overlap is valuable evidence, especially when a compiler owns the graph being compared. But a clean report is still not a social, product, or release decision. There may be tests not represented in the graph, user intent not represented in the syntax, or operational timing that makes the change wrong even when the structure appears compatible.

Sley's answer is not to remove people from the loop. It is to stop wasting their attention on ambiguity that the language and harness can make explicit.

The Architectural Response

Sley now separates five decisions that ordinary tooling often collapses: inspect, propose, preview, accept, and promote. The compiler may expose a graph slice without authorizing an edit. It may validate a graft without applying it. It may report a conflict-free bounded comparison without declaring the merge safe. It may verify a project without deploying anything.

This separation is the guardrail. It gives external tools useful structure while keeping consequential authority with the surrounding operator workflow. It also produces smaller, cleaner handoffs. A future session can inherit reports, diagnostics, and explicit next actions instead of re-reading an entire repository and reconstructing every prior decision from prose.

The design also changes what a Sley integration should expose first. The safest initial bridge is not a powerful mutation API. It is a bounded interpreter for questions: show me the relevant structure, lint this scope, plan the graft, preview the write, verify the staged state, and return evidence with named limits. Write authority can come later, after the surrounding process knows what kind of report it is accepting.

That is why the checkpoint is more important than its individual mechanics. It turns Sley from a language thesis into an operating boundary. The language is not only describing code to agents. It is also describing where an agent's authority stops.

What Changed

The recorded checkpoint carries 42 report schemas, 128 contract fixtures, 23 accepted corpus cases, 43 rejected corpus cases, 199 integration checks, and 23 of 23 local v1 gate checks. Those counts matter because they make the claim inspectable. They are not the most important change.

The deeper shift is that Sley now looks less like a language searching for a demonstration and more like a review surface designed for continuous software change. Its strongest public argument is no longer novelty. It is that speed, structure, and restraint can occupy the same workflow.

The public claim is deliberately scoped. The source note does not say every future checkout is green, every merge is safe, every category proof is complete, or every host action is authorized. It says the August checkpoint produced a bounded evidence packet and that the new surfaces keep inspection, planning, comparison, mutation, and promotion from collapsing into one vague act.

That restraint is not modesty for its own sake. It is part of the product argument. Tools that want to participate in serious software change need to publish their limits as clearly as their capabilities.

What Comes Next

The public repository, product site, evidence packet, and Chronicle trail must stay synchronized as the implementation advances. Category claims should remain attached to criteria. New tool surfaces should begin with the least authority they need. Semantic automation should earn promotion through adversarial fixtures and round-trip evidence rather than enthusiasm.

The next useful milestone is not a louder demo. It is a stronger review loop: more adversarial cases, clearer report contracts, sharper public examples, and a product surface that makes the safe path feel like the natural path. Sley should make it easy to ask what changed, why the compiler believes it, what evidence belongs to the staged bytes, and which human decision remains open.

That is the path forward for Sley: make the work more structural, make the proof easier to inherit, and never let a useful report quietly become permission for an action it was not designed to authorize.