myc

Self-custodial remote signer for Radroots apps
git clone https://radroots.dev/git/myc.git
Log | Files | Refs | README | LICENSE

AGENTS.md (2114B)


      1 # myc - code directives
      2 
      3 - this repo defines `myc`, the Radroots signer service
      4 - treat signing, key material handling, approval flows, session control, and signer-facing transport as security-critical repo-owned behavior
      5 - do not make this repo responsible for relay storage, relay fanout, relay tenancy, SDK contract generation, wallet product flows, platform-wide artifacts, publication, promotion, or deployment transport unless explicitly assigned here
      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
      8 - do not invent requirements, APIs, dependencies, release processes, or external integration behavior
      9 - do not depend on private repositories, unpublished artifacts, local machine layouts, absolute paths, or internal monorepo context
     10 - keep key material handling narrow, explicit, auditable, and separated from presentation or transport glue
     11 - prefer typed request, response, approval, session, and error models over stringly or implicit state
     12 - keep public docs, manifests, tests, generated artifacts, and contract surfaces aligned with behavior changes
     13 - avoid hidden production panics; use typed errors for expected failure modes
     14 - avoid `unsafe` unless it is strictly necessary, locally justified, and documented with nearby invariants
     15 - tests and examples must not include real secrets, realistic private keys, reusable credentials, or sensitive event content
     16 - preserve least-privilege boundaries and explicit trust boundaries; stop and report concerns before weakening security, privacy, or key custody boundaries
     17 - use checked-in, repo-owned validation first; run the smallest documented validation that credibly covers the change
     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