Trabaja con nosotros.

No. El análisis de código y dependencias corre localmente en el IDE. A Oryon se sincronizan findings, metadatos y el contexto mínimo necesario para IA, autenticación o dashboard.

Se sincronizan findings, dependencias, metadatos del proyecto o repositorio, supresiones compartidas e histórico de scans. El objetivo es conservar memoria de equipo y reporting, no mover el repositorio completo a la nube.

No por defecto. Oryon usa el contexto mínimo necesario para enriquecer o clasificar findings, normalmente snippets y metadatos relevantes, no una copia completa del código fuente.

Sí. El análisis de código y dependencias corre localmente en el editor. El dashboard queda como capa de memoria compartida, reporting y seguimiento cuando el equipo realmente lo necesita.

No. Puedes usar la extensión de forma local sin depender del dashboard. Vincular el repositorio solo hace falta si quieres memoria compartida, histórico, dependencias sincronizadas y supresiones reutilizables entre scans.

Sí. La vinculación al dashboard es por proyecto o repositorio, no un todo o nada. Puedes empezar con un piloto local-first y solo sincronizar los repositorios donde realmente quieras memoria compartida, histórico o seguimiento de equipo.

El triage está diseñado para ser conservador. Solo se descarta un finding si dos pasadas coinciden en `drop`; ante conflicto, timeout, error o incertidumbre, Oryon mantiene el finding.

Ambas. Puede analizar cambios mientras editas o guardas, y también lanzar un escaneo más amplio del workspace cuando quieres revisar el estado general del repositorio.

Sí. Además de detectar findings, añade explicaciones, contexto técnico y, cuando aplica, guía de remediación para que el developer entienda qué pasa y qué debería revisar primero.

Sí. Oryon está pensado para que las decisiones útiles sobrevivan al siguiente scan. Las supresiones compartidas y la memoria por repositorio reducen ruido sin obligar a repetir el mismo trabajo cada vez.

No. Oryon mejora la señal temprana dentro del workflow del developer, pero no sustituye revisiones manuales, auditorías especializadas o pruebas ofensivas cuando el riesgo o el contexto las requieren.

Está pensado justo para reducir ese problema. El prefiltrado heurístico elimina bastante ruido inocuo, el triage intenta separar lo relevante de lo dudoso y las supresiones compartidas evitan que el equipo vuelva a pelearse con el mismo falso positivo en cada scan.

Hoy el mejor encaje es VS Code y forks compatibles como Cursor, VSCodium, Windsurf, Antigravity o Code - OSS, donde el modelo local-first y el flujo dentro del editor generan la ventaja más clara.

Sí. Oryon no obliga a sustituir tu stack actual. Muchos equipos lo usan para adelantar la señal al IDE y mantener un workflow diario más útil, mientras conservan escáneres o controles adicionales en CI y plataforma.

Hoy el núcleo es la extensión de VS Code, el dashboard y API de Oryon, la sincronización por proyecto, las supresiones compartidas, la autenticación con Google, Magic Link y SSO, y los borradores de issues en GitHub o GitLab. La API también permite ingest desde CI.

Sí. Oryon puede preparar borradores de issue para acelerar el paso del hallazgo a la acción, manteniendo el contexto técnico y el resumen del problema más claros para el equipo.

Sí, aunque el comportamiento exacto depende del tamaño, la estructura y el lenguaje del repositorio. En equipos grandes lo sensato es pilotarlo sobre un repositorio representativo y ajustar el workflow antes de ampliarlo.

No. El valor inicial debería llegar dentro del editor. CI, API y sincronización al dashboard sirven para ampliar coordinación y reporting, pero no son un requisito para empezar a evaluar la extensión ni para probar el flujo local-first.

Para la experiencia completa sí. La cuenta da acceso al dashboard, autenticación, memoria compartida por repositorio, histórico de scans y sincronización entre la extensión y la plataforma.

Ganas memoria compartida. Las supresiones, findings, dependencias y el histórico quedan ligados al mismo fingerprint del repositorio, así que los siguientes scans no empiezan desde cero.

No. El dashboard aporta coordinación, reporting e histórico, pero la capa de valor inicial sigue estando en la extensión. Puedes empezar por el editor y ampliar al dashboard cuando el equipo necesite memoria compartida.

Sí. Oryon está preparado para escenarios individuales y de organización, de modo que puedas trabajar sobre un espacio personal o colaborar dentro de un workspace compartido con controles y visibilidad de equipo.

Depende del workspace y de los permisos asociados. La idea es que la visibilidad se comparta con las personas y equipos que necesitan trabajar sobre esos proyectos, no exponer indiscriminadamente todos los resultados.

Sí. Lo razonable es que cada persona entre con su propia identidad y, si hace falta, dentro del mismo workspace o equipo. Así mantienes trazabilidad, permisos y memoria compartida sin recurrir a accesos genéricos o cuentas compartidas.

Encaja en ambos casos. Un developer individual gana feedback temprano dentro del IDE; un equipo gana además dashboard, contexto compartido por repositorio, histórico de scans y memoria común sobre falsos positivos.

Sí. Oryon tiene un plan Free para empezar a probar el workflow y evaluar el encaje básico antes de pasar a planes con más capacidad, más proyectos o funciones de equipo.

La cancelación evita la renovación del siguiente periodo. Normalmente mantienes acceso hasta el final del periodo ya pagado y luego el workspace pasa al estado o límites que correspondan según el plan disponible.

Sí. El cambio de plan afecta a la cuenta, al dashboard y a los límites disponibles, no a la instalación base de la extensión. La experiencia no debería requerir reinstalar el plugin.

Sí. Dependiendo del caso, Oryon puede ayudar con dudas técnicas, integración inicial, evaluación del workflow y definición del piloto para que el equipo no tenga que descubrir todo por ensayo y error.

Sí. De hecho es lo recomendable. Lo normal es empezar con uno o dos repositorios representativos, validar calidad de señal, fricción del workflow y necesidad real de dashboard antes de expandirlo a más developers.

La idea del producto no es forzar permanencias artificiales. Lo normal es poder empezar pequeño, validar encaje y decidir si amplías uso. Si cancelas, la renovación futura se detiene y el acceso se mantiene hasta el final del periodo ya pagado.