Sley

Documentation brief

Sley Documentation

A practical public orientation: what you can use today, what the language optimizes for, and how to onboard safely.

What Sley is for

Sley is a compiler-oriented language surface for people and agents who need fast edits with strong evidence. Use it when your workflow values reproducibility, scope control, and explicit planning over ad-hoc text patching.

  • Language-level boundaries for authority and side-effects
  • Deterministic planning and edit receipts for machine handoff
  • Token-aware workflows where context stays scoped and reviewable

Quick start

Use this shortest path for a first successful loop with low context overhead.

# 1) Sanity-check the language surface
sley doctor --json .

# 2) Inspect structure and graph intent
sley ast --json main.sley
sley graph --json --slice <node-id> main.sley

Starter page: Sley tutorial

Public command surface

The public API is oriented around checks, graph views, and verified edit planning. Use JSON outputs by default so tools can compare receipts across hands.

  • sley ast
  • sley graph
  • sley query
  • sley lint
  • sley plan
  • sley verify
  • sley doctor

Language-first workflow

Sley prefers explicit task declarations, typed task calls, schema-linked JSON reports, and deterministic plan outputs. This keeps token pressure low by preserving edit structure instead of re-explaining intent on every cycle.

  • Scope every operation to the smallest valid edit slice
  • Read diagnostics before mutation
  • Use `--dry-run` mode for repair previews

Hands-on walkthrough

From a fresh checkout, begin with release-boundary checks, then run readiness commands in this sequence. Each stage emits JSON artifacts intended for deterministic comparison across handoffs.

# Step 1: baseline health
sley doctor

# Step 2: inspect structure
sley ast --json .

# Step 3: inspect planned edits
sley plan --json --graft-templates .

# Step 4: lock behavior with verification
sley verify --json .

Evidence and safety boundaries

Every public-facing route points to bounded claims and open references only. Internal runtime specifics remain intentionally omitted from the public mirror until release posture and doctrine allow a wider public reveal.

  • Source and docs links are canonical: GitHub, OpenForge, and sleylang.org
  • Protected implementation details stay off the public brief
  • Verification artifacts stay the compatibility boundary for external review

Operational references

Public release posture, comparison posture, benchmark posture, and release notes are surfaced through the Sley source pack, Greyforge OpenForge, and Greyforge Chronicles. Those are the stable sources for claims and public links.

  • Read `/chronicles/sley-zjx-agent-native-stack` on greyforge.tech
  • Track OpenForge repo posture from the same source chain
  • Use llms.txt for crawler-facing summary and links

Public claim summary

  • Canonical claim: agent-native structural programming for compiler-mediated, human-reviewed software change.
  • World-first category claim: cite only with the public evidence packet, claim manifest, and prior-art source pack.
  • Release claim: the public v1 gate passes, while public release remains blocked by strict parity, proof bundle, and operator approval.
  • May 27 checkpoint: the local v1 gate remains green with 198 integration checks, and Sley-owned source coverage now includes report-builder registry dispatch plus selected runtime source-call, FileRead, and seeded host-effect return paths.

Evidence packet: docs/SleyClaimEvidence.md

Claim manifest: docs/SleyClaimManifest.json

Prior-art source pack: docs/SleyPriorArtSourcePack.md

Walkthrough map

  1. Read this brief and the walkthrough before any edits.
  2. Verify baseline posture: sley doctor --json .
  3. Inspect structure and graph slices before planning: sley ast --json . and sley graph --json --slice <node-id> .
  4. Produce structured plans and only then promote: sley plan --json --graft-templates .
  5. Validate again with sley verify --json . and move forward only if checks pass.

Release-friendly onboarding

The easiest onboarding path is intentionally conservative: confirm baseline checks, generate structured reports, and only then promote deeper edits after lint and verify pass.