cli

Command-line interface for Radroots
git clone https://radroots.dev/git/cli.git
Log | Files | Refs | README | LICENSE

AGENTS.md (2166B)


      1 # cli - code directives
      2 
      3 - this repo defines `radroots_cli`, the Radroots command-line interface; the primary binary is `radroots`
      4 - treat this repo root as the source of truth for source, user-facing command behavior, repo-local validation, docs, and release-candidate readiness
      5 - do not make this repo responsible for platform-wide signed artifacts, builder selection, publication, promotion, deployment transport, relay internals, signer internals, or SDK internals unless the public CLI contract explicitly changes
      6 - 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
      7 - inspect the relevant implementation, tests, manifests, and docs before changing behavior; read `README.md` and `Cargo.toml` before broad edits
      8 - do not depend on private repositories, unpublished artifacts, local machine layouts, absolute paths, or internal monorepo context
      9 - keep public docs, manifests, tests, generated artifacts, and contract surfaces aligned with behavior changes
     10 - preserve clear boundaries between argument parsing, configuration loading, service clients, domain logic, and output formatting
     11 - prefer explicit typed models, deterministic behavior, narrow side effects, and direct service boundaries over stringly or implicit behavior
     12 - avoid hidden production panics; use typed errors for expected failure modes
     13 - avoid `unsafe` unless it is strictly necessary, locally justified, and documented with nearby invariants
     14 - 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
     15 - use checked-in, repo-owned validation first; run the smallest documented validation that credibly covers the change, and use release acceptance validation for production candidates
     16 - if validation cannot run, report exactly what was skipped and why; never claim validation passed unless it actually ran
     17 - keep commits focused and reviewable, using `<scope>: <imperative summary>` unless a repo convention overrides it