sdk

Radroots SDK and bindings
git clone https://radroots.dev/git/sdk.git
Log | Files | Refs | README

AGENTS.md (2388B)

      1 # radroots_sdk - code directives
      2 
      3 - this repo owns the Radroots `sdk` workspace, including Rust SDK APIs, generated language bindings, FFI layers, WebAssembly surfaces, package metadata, and SDK validation flows
      4 - own generated SDK artifacts through their source generators, schemas, templates, and public contracts, not by hand-editing generated output
      5 - do not make this repo responsible for downstream app repos, private layout, platform deployment, publication policy outside this repo's public contract, or compatibility packages unless explicitly represented here
      6 - work spec-first for public SDK behavior; do not invent packages, bindings, exports, compatibility layers, or publishing behavior
      7 - prefer the smallest coherent change that fully addresses the request; do not mix unrelated cleanup, speculative refactors, compatibility scaffolding, or roadmap work into the same change
      8 - inspect the relevant implementation, tests, manifests, specs, package metadata, and docs before changing behavior
      9 - do not depend on private repositories, unpublished artifacts, local machine layouts, absolute paths, or internal monorepo context
     10 - keep generated bindings reproducible from checked-in source contracts
     11 - preserve root imports, package boundaries, and public API shapes unless the task explicitly changes the SDK contract
     12 - when behavior changes affect generated outputs, update the source contract and regenerate through repo-owned tooling rather than hand-editing artifacts
     13 - prefer explicit typed models, deterministic behavior, narrow side effects, and direct service boundaries over stringly or implicit behavior
     14 - avoid hidden production panics; use typed errors for expected failure modes
     15 - avoid `unsafe` unless it is strictly necessary, locally justified, and documented with nearby invariants
     16 - do not expose secrets, private keys, credentials, tokens, invite codes, private identifiers, sensitive user data, or sensitive event content in code, logs, tests, fixtures, docs, or examples
     17 - use checked-in, repo-owned validation first; prefer narrow contract tests plus repo-wide validation for generated-code or package-surface changes
     18 - if validation cannot run, report exactly what was skipped and why; never claim validation passed unless it actually ran
     19 - keep commits focused and reviewable, using `<scope>: <imperative summary>` unless a repo convention overrides it