v1.0.0

[1.0.0] - 2026-07-11

The first tagged release of RaySpec — file-deployable AI infrastructure. Describe
a product's backend in one declarative version: '1.0' spec, and the platform
stands up the running backend from that single file.

Added

• Declarative spec engine. One version: '1.0' language with two profiles —
  a full-control backend profile (metadata, stores, api, agents,
  tooling, triggers, handlers, extensions, deployment) and a
  higher-level product profile (selected by a top-level product: section).
  Specs are parsed fail-closed: an unknown key is rejected, not ignored. The
  deploy pipeline validates, diffs the required migration, gates destructive
  changes, and materializes the declared backend.
• Accounts, authentication, and tenancy. First-class organizations,
  memberships, users, API keys, and JWT/OIDC — all owned by the platform. Every
  query against tenant-owned data carries a tenant predicate, enforced
  structurally by a single fail-closed, deny-by-default database chokepoint.
• Four in-process agent backends behind one neutral interface. OpenAI Agents,
  Anthropic's Claude Agent SDK, Pi, and OpenAI Codex all run in-process behind a
  single neutral Backend interface; an agent is declared once and its backend is
  chosen from the spec. A cross-backend parity suite holds every adapter to the
  same neutral contract.
• A generated, tenant-scoped data layer. Declared stores become
  Postgres/Drizzle tables with the tenancy and data-lifecycle columns injected
  automatically; migrations are diffed and passed through a safety gate before
  they apply, including a from-clean-database bootstrap check.
• Durable background work and a run journal. Long-running agent runs and
  scheduled triggers execute off-request on a durable worker, with a per-step,
  append-only, tenant-scoped run journal that is the single source of truth for
  replay, cost accounting, and audit.
• Reusable ingress capabilities. A product profile can request reusable
  capabilities by name — audio/transcription, file ingest, multi-turn
  conversation, and structured records — rather than writing the ingress plumbing.
• The rayspec CLI. deploy stands up a product's declared backend from its
  spec (validate → derive the required migration → plan → apply). Read-only
  diagnostics — doctor (static validation), plan (a read-only deploy preview
  with an optional shadow-apply), openapi (emit an OpenAPI document for a
  product's declared views), and gen-handler (render a bounded escape-hatch
  handler) — plus a local-dev dev group (gen-secrets, db,
  bootstrap-tenant).
• The rayspec-serve boot server. An environment-driven boot that fails
  closed on missing secrets, applies the committed migration chain, and serves the
  platform — with a loud banner stating its trusted, single-node, not-yet-hardened
  posture.

Security

• Security by construction from the first boot: tenant isolation enforced by the
  fail-closed chokepoint (with a CI cross-tenant test), no plaintext secrets, an
  untrusted-content tool-dispatch trust boundary, an out-of-band audit journal,
  and per-backend credential isolation. The additional hardening required for
  untrusted, multi-tenant, public-internet hosting is a separate layer and is
  deliberately not part of the core — see SECURITY.md.