tylerg/auth-yes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
auth-yes/AGENTS.md

3.0 KiB
Raw Blame History

AGENTS.md — Auth-Yes System Guidelines & Operating Protocol

1. Project Context

Auth-Yes is a standalone, ultra-low-friction, zero-trust Identity and Access Management (IAM) fabric and WebAuthn Passkey authority.

  • Runtime: Deno 2.x (TypeScript 5.x)
  • Architecture: Modular Deno Workspace (sdk/, server/, ui/, spire_ffi/, infra/)
  • Web API & SSR: Hono with pure Hono SSR JSX (Strictly React-free)
  • Workload Mesh: ConnectRPC daemon + Rust SPIFFE/mTLS FFI crate (spire_ffi/)
  • Data Layer: Dedicated PostgreSQL 18 + Valkey 8 (L1/L2 RESP3 Client Tracking)
  • Cookie Scope: Wildcard .atyg.org domain scoping with host-collision sweep

2. Key Architecture Standards

  1. Zero-Dependency SDK: @auth-yes/sdk must remain 100% free of backend/database imports. ConnectRPC contracts live in sdk/gen/.
  2. Security: Session invalidation and revocation MUST always be handled server-side (deleteCookie across host and wildcard domains).
  3. Quality Gates: Every PR must pass deno fmt, deno task lint, deno task check, and deno test.
  4. Dual Remote & SDK Distribution: Development is tracked on GitHub (origin: git@github.com:mrteye/auth-yes.git). All commits and SDK changes must be mirrored to Gitea (gitea: git@git.atyg.org:tylerg/auth-yes.git) so that external agents (e.g. Jules) and unauthenticated local projects can consume raw SDK modules via https://git.atyg.org/tylerg/auth-yes/raw/branch/main/sdk/mod.ts.

3. Strict Operating Protocol: Methodical Deliberation & Approval Gate

  1. Read-Only First & Deep Context Preservation:
    • When asked to investigate, audit, analyze, critique, or report, NEVER make assumptions or jump directly into modifying files or pushing commits.
    • Spontaneous changes without team alignment break architecture and lose context. Always deliberate methodically across at least two levels of reasoning before proposing changes.
  2. Mandatory Reporting & Options Presentation:
    • Inspect files and architecture using read-only tools.
    • Synthesize and present a structured markdown report detailing:
      • Exact state vs. master specification
      • Root causes of discrepancies or missing features
      • Proposed remediation options with trade-offs
  3. Strict Gate on Code Modification:
    • Offer potential code changes clearly, but NEVER execute edits (write_to_file, replace_file_content) or git commits until the user explicitly reviews the proposal and confirms execution.
  4. Standard Task Protocols (tasks/path.md):
    • Follow the standardized engineering lifecycle: tasks/plan.md \rightarrow tasks/audit-1.md \rightarrow tasks/do.md \rightarrow tasks/audit-2.md, with tasks/debug.md for hermetic root-cause analysis.

4. History & Context Link

This repository was cleanly extracted from ed-droid.