Saltar al contenido principal

Nativo del repositorio, por diseño

StrayMark no tiene SaaS, no tiene dashboard, no tiene una segunda fuente de verdad. Cada artefacto — Charters, AILOGs, reglas de agentes, evidencia de compliance — vive como archivo versionado en tu repositorio de git, junto al código que gobierna.

Por qué importa​

  • El razonamiento viaja con el código. Un git blame sobre una línea peliaguda lleva al commit, que lleva al AILOG, que lleva al Charter, que lleva a los riesgos declarados de antemano. Sin herramienta a la que loguearse, sin link roto de una página de Confluence movida.
  • Diff = gobernanza. Cuando cambia STRAYMARK.md, es un PR con revisores y discusión. Cuando falta un AILOG para un commit no trivial, CI lo detecta. El mismo flujo de git que ya usas es el único flujo.
  • Sin vendor lock-in. El framework es Markdown plano más un CLI en Rust. Ambos son MIT y self-hosted. Salir de StrayMark es rm -rf .straymark/ — y tu historia no se va contigo.
  • Los forks son ciudadanos de primera. Las organizaciones pueden forkear el framework, fijar una versión y evolucionar sus propias reglas. El comando update-framework del CLI respeta ese pinning.

Cómo funciona​

tu-repo/
├── STRAYMARK.md                  # Reglas unificadas — lo primero que leen los agentes
├── .straymark/
│   ├── 00-governance/            # AGENT-RULES, políticas de doc, quick reference
│   ├── 01-charters/              # CHARTER-NN-slug.md
│   ├── 02-ailogs/                # AILOG-YYYYMMDD-NN-slug.md
│   ├── 03-decisions/             # AIDEC, ADR
│   ├── 04-models/                # MCARD
│   ├── 05-security/              # SEC, ETH, DPIA
│   ├── 06-evolution/             # TDE, deprecations
│   └── audits/CHARTER-NN/        # Reportes de auditoría externa
└── src/...                       # Tu código real

El CLI (straymark validate, straymark audit, straymark compliance) opera sobre el sistema de archivos, de forma determinista. Sin daemons, sin sync en background.

Aprende más​